Dear Linus,
It seems like there has been the expectation that the 2.5
tree was about to be opened for at least the last two months.
Would you be willing to state what the remaining impediments
are to opening the tree? If you do so, it might help us
more quickly resolve the remaining issues so we can begin
implementing the many changes we have anticipated working on
in the 2.5 tree.
That said, I'll note that gaining clear agreement or at least
consensus in the design of the new 2.5 driver model may be a
prerequisite to opening the 2.5 tree. I'm not sure whether
your intent is to wait for further design discussions to take
place regarding other areas of major change.
Best wishes,
Miles
Miles Lane wrote:
>
> Dear Linus,
>
> It seems like there has been the expectation that the 2.5
> tree was about to be opened for at least the last two months.
Most likely we are
(a) waiting for stuff to get merged from Alan's tree, and
(b) waiting for new VM and blkdev stuff in Linus tree to settle down and
prove itself stable
Personally I am still fixing bugs (2.4 stuff) so I could care less :)
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
From: Jeff Garzik <[email protected]>
Date: Sun, 28 Oct 2001 01:04:23 -0400
Most likely we are
(a) waiting for stuff to get merged from Alan's tree, and
For the record, I do not feel comfortable at all with forking
2.4.x over to Alan until all of the non-trivial bits of the
AC patches are merged into Linus's tree.
In particular, the quota stuff, which has sat in Alan's tree forever.
If Linus is ignoring the changes it probably is for a good reason
but it would be nice for him to let Alan know what that reason is :-)
Franks a lot,
David S. Miller
[email protected]
On Sunday 28 October 2001 06:04, Jeff Garzik wrote:
> Miles Lane wrote:
> > Dear Linus,
> >
> > It seems like there has been the expectation that the 2.5
> > tree was about to be opened for at least the last two months.
>
> Most likely we are
> (a) waiting for stuff to get merged from Alan's tree, and
> (b) waiting for new VM and blkdev stuff in Linus tree to settle down and
> prove itself stable
>
> Personally I am still fixing bugs (2.4 stuff) so I could care less :)
Basicly you could restate it like this:
2.5 will be when:
(a) Linus is satisfied with the patches from Alan's tree
(b) Alan is satisfied with the patches in Linux's tree. (Most notably VM
stuff)
Since some of the stuff in Alan's tree is for special features/hardware, it
might get droped when Alan gets the responsiblity for a truly stable kernel.
So (b) is the most important condition.
The latest ac patch was getting smaller, watch for it for reach 0 :)
It might be an idea to consider a two or three tiered release model like
debian. E.g. experimental/testing/stable.. Right now 2.2 is stable, 2.4 is
testing closing to stable, but we lack an experimental branch, although Alan
has taken some stable "experimental" stuff. A truly experimental 2.4 would
nice even if the source incompatable changes was still postponed for 2.5. And
offical post-patches for the stable releases could also be usefull, instead
of people recomminding kernels from Redhat/Suse. Official post-patches would
IMHO have saved 2.4.11 and 12.
Disclaimer: But releasemodels are religius questions and hard to argue or
prove. :-)
regards
`Allan
On Oct 27, 2001 22:46 -0700, David S. Miller wrote:
> In particular, the quota stuff, which has sat in Alan's tree forever.
> If Linus is ignoring the changes it probably is for a good reason
> but it would be nice for him to let Alan know what that reason is :-)
AFAIK (not much, since I don't use quotas), the on-disk quota format used
by Alan's tree was changed to support 32-bit UID/GIDs, which makes it
incompatible with that used in the Linus tree. However, there was also
some quota merging done in 2.4.13 or so, which _may_ have resolved this.
Yes, it's vague, but nobody else has answered yet. I'm only aware of these
issues because the ext3 code had to work with both trees, and the quota
compat stuff was removed in the most recent ext3 release. That may have
only been an in-kernel API issue and not the on-disk format, I don't know.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
> On Oct 27, 2001 22:46 -0700, David S. Miller wrote:
> > In particular, the quota stuff, which has sat in Alan's tree forever.
> > If Linus is ignoring the changes it probably is for a good reason
> > but it would be nice for him to let Alan know what that reason is :-)
>
> AFAIK (not much, since I don't use quotas), the on-disk quota format used
> by Alan's tree was changed to support 32-bit UID/GIDs, which makes it
> incompatible with that used in the Linus tree. However, there was also
> some quota merging done in 2.4.13 or so, which _may_ have resolved this.
Actually there were two quota patches in Alan's tree. The first one was
just some fixes in quota code - some locking changes, race fixes, dynamic allocation
of quota structures. This patch went into 2.2.12.
The second patch is patch which implements new quota format. It makes
changes in quotactl() interface and other changes visible in userspace.
I think that is the reason why Linus doesn't want it in 2.4 and I agree with him.
> Yes, it's vague, but nobody else has answered yet. I'm only aware of these
> issues because the ext3 code had to work with both trees, and the quota
> compat stuff was removed in the most recent ext3 release. That may have
> only been an in-kernel API issue and not the on-disk format, I don't know.
>
> Cheers, Andreas
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Linus has waited long enough to open up 2.5 that both he
and Alan are failing to resist the temptation to make
destabilizing changes in 2.4, with the result that
the day of branching is perpetually postponed.
What we have learned from the present experience is that
no kernel branch is really stable until it is entirely in
Alan Cox's hands. Prior to that time, both Linus and Alan
are in "let's play with this" mode. This has some benefits.
I think it's safe to say, though, that having two semi-stable
branches is inferior to having one stable branch that we
can rely on and one development branch that we can work on.
Perhaps a better approach in the future would be for Linus
to turn the kernel over to Alan as of 2.6.0 and to open 2.7.0
immediately. That would be an incentive for Linus to refrain
from calling unstable kernels "stable" ones, and would allow
Alan to maintain 2.6 with the single aim of increasing
stability, according to one person's idea of what it takes
to do that. Alan's "-ac" kernels would take the place of
Linus's "pre" kernels. Linus would no longer produce "pre"
kernels because he's worse than Alan at maintaining a stable
kernel (as he admits) and anyway he would be busy with 2.7.
Having suggested, this, I'll remind everyone that Linus
and Alan can do whatever the hell the like. Which is
what I like about Linux.
--
Thomas Hood
sounds like more complication to me. i personally think both do a great
job at getting the job done. sure there are problems with any source
tree. but adding more version numbers and turning kernels over to other
people doesnt seem like the solution for making anything more stable.
using the pre kernels seems to be the way for things to become stable.
what need is there for a 2.5 tree right now? when linus feels like
opening te 2.5 tree it till happen. just sit back and wait and enjoy the
ride. if your too impatient for stability or new source trees remember
this is an open source project.
On 30 Oct 2001, Thomas Hood wrote:
> Linus has waited long enough to open up 2.5 that both he
> and Alan are failing to resist the temptation to make
> destabilizing changes in 2.4, with the result that
> the day of branching is perpetually postponed.
>
> What we have learned from the present experience is that
> no kernel branch is really stable until it is entirely in
> Alan Cox's hands. Prior to that time, both Linus and Alan
> are in "let's play with this" mode. This has some benefits.
> I think it's safe to say, though, that having two semi-stable
> branches is inferior to having one stable branch that we
> can rely on and one development branch that we can work on.
>
> Perhaps a better approach in the future would be for Linus
> to turn the kernel over to Alan as of 2.6.0 and to open 2.7.0
> immediately. That would be an incentive for Linus to refrain
> from calling unstable kernels "stable" ones, and would allow
> Alan to maintain 2.6 with the single aim of increasing
> stability, according to one person's idea of what it takes
> to do that. Alan's "-ac" kernels would take the place of
> Linus's "pre" kernels. Linus would no longer produce "pre"
> kernels because he's worse than Alan at maintaining a stable
> kernel (as he admits) and anyway he would be busy with 2.7.
>
> Having suggested, this, I'll remind everyone that Linus
> and Alan can do whatever the hell the like. Which is
> what I like about Linux.
>
> --
> Thomas Hood
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
************************
"If you want a picure of the future, imagine a boot smashing a human face"
- 1984, George Orwell
email: [email protected] * website: http://www.23.org/~lost
************************
On Tue, 2001-10-30 at 16:39, lost wrote:
> sounds like more complication to me. i personally think both do a great
> job at getting the job done. sure there are problems with any source
> tree. but adding more version numbers and turning kernels over to other
> people doesnt seem like the solution for making anything more stable.
[SNIP]
For my .02, I completely disagree with you. I'll explain in a minute.
> On 30 Oct 2001, Thomas Hood wrote:
[SNIP]
> > Having suggested, this, I'll remind everyone that Linus
> > and Alan can do whatever the hell the like. Which is
> > what I like about Linux.
> >
This has to be a strength, to be honest. I'd take this further by
proposing something else.
<Flame Retardant Suit>
To be honest, I think that any x.y.z kernel is "unstable." As we move
into a situation with an even larger installed base, I think you're
going to see a third tier become more evident: a) unstable, b) stable,
c) vendor supported. Quite frankly, if I'm making recommendations to
customers and clients for a linux installation, I typically recommend
for them to go with a vendor supplied kernel and manage it through the
vendor.
So, while I don't appreciate "massive" VM changes in the middle of my
own testing and development :-), I always treat every new kernel
iteration as potentially "unstable" and operate on the "if it ain't
broke, don't fix it" principle on my daily use boxes (unless something
in a Linus or AC changelog looks too tempting ;-)
One can hope that the number of people reading this list plus those
keeping up with most kernel releases know what they're doing, and are a
far smaller number than those people running vendor supplied kernels and
installations. If this isn't true today, I hope it is true at some
point in the future.
Just my opinion,
Sujal
> > --
> > Thomas Hood
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> ************************
> "If you want a picure of the future, imagine a boot smashing a human face"
> - 1984, George Orwell
> email: [email protected] * website: http://www.23.org/~lost
> ************************
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---- Sujal Shah ---- PSC Labs (Progress Software) ----
Now Playing: none
> Having suggested, this, I'll remind everyone that Linus
> and Alan can do whatever the hell the like. Which is
> what I like about Linux.
Which is good because nobody has actually bothered to ask me if I'd take
on 2.4 yet and in fact I'd much rather see Marcelo do it (if he wanted to)
Alan
> The second patch is patch which implements new quota format. It makes
> changes in quotactl() interface and other changes visible in userspace.
> I think that is the reason why Linus doesn't want it in 2.4 and I agree with him.
The problem is that without it 32bit uids are useless. That means any real
world ldap using customer can't use Linus quotas.
I'd really like to figure a way the code can handle both at once
On Tue, Oct 30, 2001 at 10:44:21PM +0000, Alan Cox wrote:
> > Having suggested, this, I'll remind everyone that Linus
> > and Alan can do whatever the hell the like. Which is
> > what I like about Linux.
>
> Which is good because nobody has actually bothered to ask me if I'd take
> on 2.4 yet and in fact I'd much rather see Marcelo do it (if he wanted to)
>
> Alan
You say "yet". What would need to change before you would want to take over
2.4?
> > The second patch is patch which implements new quota format. It makes
> > changes in quotactl() interface and other changes visible in userspace.
> > I think that is the reason why Linus doesn't want it in 2.4 and I agree with him.
>
> The problem is that without it 32bit uids are useless. That means any real
> world ldap using customer can't use Linus quotas.
>
> I'd really like to figure a way the code can handle both at once
In principle both formats can exist in one kernel. The problem is how
to fit them into quotactl() syscall and don't bloat it too much. I'll try to
write something...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Full moon must be getting to me, I have to open my mouth, and howl my
opinion..
As a consultant, it seems a shame to open up a 2.5 UNTIL 2.4 is dead
stable.. When it comes to servers, I still have to recommend that my
clients stick to a 2.2 series.. Of course, I am subject to some deep
flames as well, but we defienlty aren't getting enough testing in the
-pre series each time..
So far, every 2.4.x release has followed with a series of OOPS, OOM
problems, last minite updates to the pre cycle that caused bugs.. The
2.4 series has changed So many fundamentals since 2.4.0 that it seems
more like it is still 2.3. under development.
Although a few vendors are supplying 2.4 kernels with relative success,
I cannot with good conscious say that my clients servers will be
bulletproof like the 2.2 series was..
(I say this as I just finished a work order for a new Oracle Server,
still on 2.2)
I am surely looking for the next in the 2.4 series, as it seems like we
are finally solidifying, but when I look at all of the reccomendations
for 'which 2.4' kernel to use, it is amazing at how many people are
recommending kernels or a -pre nature, or -ac - even -aa as the most
solid.. When I would expect to see everyone recommending a single
production Linus Kernel version.
Can we get a single 2.4 series kernel that has fully been tested before
moving on to even more fundamental changes?
>
> To be honest, I think that any x.y.z kernel is "unstable." As we move
> into a situation with an even larger installed base, I think you're
> going to see a third tier become more evident: a) unstable, b) stable,
> c) vendor supported. Quite frankly, if I'm making recommendations to
> customers and clients for a linux installation, I typically recommend
> for them to go with a vendor supplied kernel and manage it through the
> vendor.
>
> > Please read the FAQ at http://www.tux.org/lkml/
--
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada
we can have a 2.4 kernel that's fully tested if you can come up with a
test plan that covers all possible issues.
the fundamental problem with 2.4 has been that the VM system works when
tested by the people developing it. they hit it with everything they can
think of and are happy with the results (or if there are issues they ahve
they think they are rare enough not to be a problem)
the kernels are then released and other people hit them with different
loads and things collapse. This is the problem and the reason that 2.5 has
not been opened.
once the VM system is stable (and it sounds like we are almost there) then
the few remaining issues will be fixed as they are discovered and more
drastic changes can happen in 2.5
people seem to have the idea that linus and alan have been making all the
VM changes to the kernel for the fun of it or to test new things, they
have been making the changes becouse the old version was shown to be
horribly bad in some case.
there are other changes that have made it into the kernel during this time
and I won't go into them, but the key reason there isn't a 2.5 yet is the
VM problems.
David Lang
On 31 Oct 2001, Michael Peddemors
wrote:
> Date: 31 Oct 2001 11:18:47 -0800
> From: Michael Peddemors <[email protected]>
> To: Sujal Shah <[email protected]>
> Cc: [email protected]
> Subject: Re: What is standing in the way of opening the 2.5 tree?
>
> Full moon must be getting to me, I have to open my mouth, and howl my
> opinion..
>
> As a consultant, it seems a shame to open up a 2.5 UNTIL 2.4 is dead
> stable.. When it comes to servers, I still have to recommend that my
> clients stick to a 2.2 series.. Of course, I am subject to some deep
> flames as well, but we defienlty aren't getting enough testing in the
> -pre series each time..
> So far, every 2.4.x release has followed with a series of OOPS, OOM
> problems, last minite updates to the pre cycle that caused bugs.. The
> 2.4 series has changed So many fundamentals since 2.4.0 that it seems
> more like it is still 2.3. under development.
>
> Although a few vendors are supplying 2.4 kernels with relative success,
> I cannot with good conscious say that my clients servers will be
> bulletproof like the 2.2 series was..
>
> (I say this as I just finished a work order for a new Oracle Server,
> still on 2.2)
>
> I am surely looking for the next in the 2.4 series, as it seems like we
> are finally solidifying, but when I look at all of the reccomendations
> for 'which 2.4' kernel to use, it is amazing at how many people are
> recommending kernels or a -pre nature, or -ac - even -aa as the most
> solid.. When I would expect to see everyone recommending a single
> production Linus Kernel version.
>
> Can we get a single 2.4 series kernel that has fully been tested before
> moving on to even more fundamental changes?
> >
> > To be honest, I think that any x.y.z kernel is "unstable." As we move
> > into a situation with an even larger installed base, I think you're
> > going to see a third tier become more evident: a) unstable, b) stable,
> > c) vendor supported. Quite frankly, if I'm making recommendations to
> > customers and clients for a linux installation, I typically recommend
> > for them to go with a vendor supplied kernel and manage it through the
> > vendor.
> >
> > > Please read the FAQ at http://www.tux.org/lkml/
> --
> "Catch the Magic of Linux..."
> --------------------------------------------------------
> Michael Peddemors - Senior Consultant
> LinuxAdministration - Internet Services
> NetworkServices - Programming - Security
> Wizard IT Services http://www.wizard.ca
> Linux Support Specialist - http://www.linuxmagic.com
> --------------------------------------------------------
> (604)589-0037 Beautiful British Columbia, Canada
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>