#! incompatible -- binfmt_script.c broken?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 15 lines · Matthias Andree
I tried some of the Perl magic tricks shown in the perlrun man page with Linux 2.4.19; consider this Perl one-liner. It works on FreeBSD and Solaris, but fails on Linux. Looking at
binfmt_script.c, I believe the "pass the rest of the line as the first argument to the interpreter" is the problem with Linux. Haven't yet figured if the other boxes just use the interpreter, ignoring the arguments or if they are doing argument splitting.------------------------------------------------------------------------
#!/bin/sh -- # -*- perl -*- -T
eval 'exec perl -wTS $0 ${1+"$@"}'
if 0;
print "Hello there.\n";
------------------------------------------------------------------------
[...]
Quoted 7 lines
SuSE Linux 7.0, 7.3, 8.1 (2.4.19 kernel,
binfmt_script.cidentical to 2.4.20 BK):$ /tmp/try.pl /bin/sh: -- # -*- perl -*- -T: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... [...]
RH 8.0 with linux-2.5.50 (some early bk version, last CSET is 1.849) gives the same.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to a message not in the archiveQuoted 7 lines · Matthias Andree
Quoted 6 lines · David Ranson
Quoted 1 line · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Sure had. They were scheduled for removal in march, 2005 a long time ago.
Quoted 2 lines
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these.
Or in 2.6.10, or 2.6.27, or whatever.
Quoted 3 lines
That opportunity was
missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.
Sorry, but the new development model is that there is no "uneven" series anymore. Sure, it /might/ open for worldshattering changes, but nothing of that sort is remotely in sight right now, so...
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- devfs support was removed during 2.6
Did this affect many 'real' users?
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
devfs was broken, and very little used.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pendingI don't use any of these. I guess pcmcia-cs may be disruptive for laptop users.
Who cares what you or I use? It's a commonly acknowledged policy that "stable" releases do not remove features that are good enough for some.
Right, for a suitably large set of "some". If the set is too small...
Quoted 1 line
Linux 2.6 is not "stable" in this regard.
Right. The idea of "stable series" had to go. And went.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Horst von Brand
Quoted 7 lines · Matthias Andree
Quoted 6 lines · David Ranson
Quoted 1 line · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Quoted 6 lines
Sure had. They were scheduled for removal in march, 2005 a long time ago.
Quoted 2 lines
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these.
Or in 2.6.10, or 2.6.27, or whatever.
No. If you need to remove major components, it is only diligent to bump the minor revision and call the beast 2.7.0. At that time, not only one or two subsystems, but all that were marked deprecated for 6 months or so, should be dropped.
Quoted 5 lines
Quoted 3 lines
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
devfs was broken, and very little used.
OK. This however doesn't hold for ipfwadm (which should probably never have made it into 2.6.0 in the first place) or ipchains.
Quoted 3 lines
Quoted 1 line
Linux 2.6 is not "stable" in this regard.
Right. The idea of "stable series" had to go. And went.
So what is the point in using Linux anyhow if the kernel developers don't care for the outside world, one might ask? What is in the way of reflecting feature removals in the minor version of the project, say, remove devfs, ipfwadm, ipchains and whatnot in one go and call the new release without this legacies 2.7.0?
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Horst von BrandQuoted 39 lines · Horst von Brand
Quoted 10 lines · Matthias Andree
Quoted 8 lines · David Ranson
Quoted 1 line · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Sure had. They were scheduled for removal in march, 2005 a long time ago.
Quoted 2 lines
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these.
Or in 2.6.10, or 2.6.27, or whatever.
Quoted 3 lines
That opportunity was
missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.Sorry, but the new development model is that there is no "uneven" series anymore. Sure, it /might/ open for worldshattering changes, but nothing of that sort is remotely in sight right now, so...
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
- devfs support was removed during 2.6
Did this affect many 'real' users?
Quoted 6 lines
Quoted 3 lines
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
devfs was broken, and very little used.
Perhaps there is a cause and effect relationship? If devfs worked I don't see the need for every distro to have it's own udev (or mdev or sdev or whatever the flavor is this month).
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to a message not in the archiveQuoted 12 lines · Matthias Andree
Quoted 11 lines · Horst von Brand
Quoted 7 lines · Matthias Andree
Quoted 6 lines · David Ranson
Quoted 1 line · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Sure had. They were scheduled for removal in march, 2005 a long time ago.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these.
Or in 2.6.10, or 2.6.27, or whatever.
No. If you need to remove major components, it is only diligent to bump the minor revision and call the beast 2.7.0.
In the case of ipfwadm and ipchains, that was precisely the changeover to 2.6... ipfwadm is from 2.2, obsoleted by ipchains in 2.4, and both axed in the timespan promised.
devfs was never widely used, and was also announced to be killed by 2.6, IIRC.
Quoted 3 lines
At that time, not only one
or two subsystems, but all that were marked deprecated for 6 months or so, should be dropped.
That /is/ what is happening, modulo needless changes in version number.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
devfs was broken, and very little used.
OK. This however doesn't hold for ipfwadm (which should probably never have made it into 2.6.0 in the first place) or ipchains.
They were carried along exactly to keep the promise of killing them off by a certain date.
It seems you are going by what is called around here "Palos porque bogas, palos porque no bogas" (roughly translated, "get whipped for rowing, and get whipped for not rowing").
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Linux 2.6 is not "stable" in this regard.
Right. The idea of "stable series" had to go. And went.
So what is the point in using Linux anyhow if the kernel developers don't care for the outside world, one might ask?
Sorry, but again:
- Userland API is remarkably stable, only some stuff with intimate kernel connection have ever changed
- In-kernel API has /never/ been stable. At all. Sure, changes are much faster now (the community is larger, the tools are better, ....).
Quoted 4 lines
What is in the way of
reflecting feature removals in the minor version of the project, say, remove devfs, ipfwadm, ipchains and whatnot in one go and call the new release without this legacies 2.7.0?
It /was/ called 2.6...
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to a message not in the archiveQuoted 10 lines · Matthias Andree
Quoted 8 lines · Dmitry Torokhov
Quoted 7 lines · Matthias Andree
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
Quoted 6 lines
Quoted 3 lines
People who pass the changes can only test ones they have hardware for. For the rest they can try to validate the code by reading patches but have to rely on the submitter wrt to the patch actually working.
What I'm saying is that people (maintainer) should have a selected number of people (users) test the patches before they are merged.
Each one gets the patches from people who tested them on their machines (presumably), and the maintainer signs them off for code decency and (if he has the hardware) working on his machine too. It is very hard to get much more than that in terms of early testers. Again, one of the standard complaints here is that very few test the -rcX kernels, and then scream murder when the -final breaks. Now consider the case of proposed patches...
Yet, the solution is /very/ simple: Instead of complaining, set up a machine with the hardware that particularly interests you, get on the relevant lists, find out where the proposed patches are kept and test them. You could even add a Signed-off-by: line to the patches you check out. And again, "somebody should do..." won't get you anywhere, "here I do..." has more of a chance of success.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
In reply to a message not in the archiveQuoted 7 lines · Matthias Andree
Quoted 2 lines · Jeff Garzik
Anyone who fails to respect the kernel development process, the process of building consensus, is turn not respected, flamed, and/or ignored.
That reminds me of the old "layer 8 and 9" extensions to the OSI/ISO layering model. Layer 8: financial, Layer 9: policital.
Got that one wrong.
Layer 8: User
Layer 9: Political
Layer 10: Financial
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
RFC: Starting a stable kernel series off the 2.6 kernel
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)
One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
These problems follow from the development model.
The latest stable kernel series without these problems is 2.4, but 2.4 is becoming more and more obsolete and might e.g. lack driver support for some recent hardware you want to use.
Since Andrew and Linus do AFAIK not plan to change the development model, what about the following for getting a stable kernel series without leaving the current development model:
Kernel 2.6.16 will be the base for a stable series.
After 2.6.16, there will be a 2.6.16.y series with the usual stable rules.
After the release of 2.6.17, this 2.6.16.y series will be continued with more relaxed rules similar to the rules in kernel 2.4 since the release of kernel 2.6.0 (e.g. driver updates will be allowed).
Q:
What is the target audience for this 2.6.16 series?
A:
The target audience are users still using 2.4 (or who'd still use kernel 2.4 if they weren't forced to upgrade to 2.6 for some reason) who want a stable kernel series including security fixes but excluding many regressions.
It might also be interesting for distributions that prefer stability over always using the latest stuff.
Q:
Does this proposal imply anything for the development between 2.6.15 and 2.6.16?
A:
In theory not.
In practice, it would be a big advantage if some of the bigger changes that might go into 2.6.16 would be postponed to 2.6.17.
Q:
Why not start with the more relaxed rules before the release of 2.6.17?
A:
After 2.6.16.y following the usual stable rules, the kernel should be relatively stable and well-tested giving the best possible basis for a long-living series.
Q:
How long should this 2.6.16 series be maintained?
A:
Time will tell, but if people use it I'd expect 2 or 3 years.
Q:
Stable API/ABI for external modules?
A:
No.
Q:
Who will maintain this branch?
A:
I could do it, but if someone more experienced wants to do it that would be even better.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 21 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
These problems follow from the development model.
The latest stable kernel series without these problems is 2.4, but 2.4 is becoming more and more obsolete and might e.g. lack driver support for some recent hardware you want to use.
Quoted 7 lines
Since Andrew and Linus do AFAIK not plan to change the development model, what about the following for getting a stable kernel series without leaving the current development model:
Kernel 2.6.16 will be the base for a stable series.
[snip]
Why can't this be done by distributors/vendors?
Any vendor is free to branch off at 2.6.<whatever> and then maintain that indefinately. Why create yet-another-stable-branch?
In effect you'd be making 2.6.17+ into a 2.7.x tree and 2.6.16.y would become a 2.6 tree in 2.4.x style, with all the backporting problems and vendor skew that 2.4.x suffered from.
Personally I don't like this proposal. In my oppinion 2.6 + the -stable branch as we have it now works well and people who want userspace & kernel in sync are perfectly free to use vendor kernels (which is also the recommended thing to do for most users as far as I know).
Just my 0.02euro.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
Quoted 9 lines
thanks,
greg k-h
-
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/
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
Enterprise products are suited for production servers, school/government/companies desktops and not for "enthusiasts" or for small kernel projects (they obviously cant write drivers or patches for custom distro kernels). Those enthusiasts have to get mad with performance regressions, new incompatibilities, new crashes etc.
My suggestion was to release a 2.6.X kernel every 6months reducing kernel development fragmentation between different distros and giving away stabler stuff.
Michele
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · M.
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
If there are "small projects writing" their own wifi driver, they should try to get it included in the kernel ASAP. Then they won't have to track the changes, as the person making the changes will automatically change their little driver to keep it working after the changes. Drivers very rarely impact the stability of the rest of the kernel.
It initially gets added as "EXPERIMENTAL" so the user can choose whether to even use it or not.
All it takes is for the "small project" to build their own git tree, and then ask the Linus or Andrew to pull it. It should get added pretty easily, so long as the code looks pretty. :-) It is really that simple. There is no logical reason for any external driver not to be added into the main kernel, so why do people not want to add them?
James
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RFC: Starting a stable kernel series off the 2.6 kernel
<dragging the converstation back to lkml, where it belongs...>
Quoted 11 lines · M.
Quoted 10 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
Quoted 7 lines
Quoted 3 lines
thanks,
greg k-h
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
If you are a user that wants this kind of support, then use a distro that can handle this. Obvious examples that come to mind are both Debian and Gentoo and Fedora and OpenSuSE, and I'm sure there are others.
But if you are a developer, you can usually stay up to date by tracking the main releases, which should be about once a month. If you have problems porting your stuff to the latest kernel when you need to submit it for inclusion, there are lots of people to help point you in the proper direction for what is needed to be done.
Quoted 5 lines
Enterprise products are suited for production servers, school/government/companies desktops and not for "enthusiasts" or for small kernel projects (they obviously cant write drivers or patches for custom distro kernels). Those enthusiasts have to get mad with performance regressions, new incompatibilities, new crashes etc.
Sure, then use a different distro for them. That's why Linux has so many different ones, they all are targeted at different users.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 39 lines · Greg KH
<dragging the converstation back to lkml, where it belongs...>
Quoted 11 lines · M.
Quoted 10 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
Quoted 7 lines
Quoted 3 lines
thanks,
greg k-h
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
If you are a user that wants this kind of support, then use a distro that can handle this. Obvious examples that come to mind are both Debian and Gentoo and Fedora and OpenSuSE, and I'm sure there are others.
But if you are a developer, you can usually stay up to date by tracking the main releases, which should be about once a month. If you have problems porting your stuff to the latest kernel when you need to submit it for inclusion, there are lots of people to help point you in the proper direction for what is needed to be done.
Quoted 5 lines
Enterprise products are suited for production servers, school/government/companies desktops and not for "enthusiasts" or for small kernel projects (they obviously cant write drivers or patches for custom distro kernels). Those enthusiasts have to get mad with performance regressions, new incompatibilities, new crashes etc.
Quoted 7 lines
Sure, then use a different distro for them. That's why Linux has so many different ones, they all are targeted at different users.
thanks,
greg k-h
<sorry for the direct reply>
makes sense, but are you sure having distros like Debian, enterprise products from redhat etc using the same 6months release for their stable versions does not translate in minor fragmentation on kernel development and in benefits for every user?
Under this light i think a 6months cycle starts to mean something when stable distros gets older and older (debian and redhat enterprise are released every 18/24 months) and developers and who wants bleeding edge features can always use Fedora, openSUSE, Gentoo etc. Another advantage would be to benefit external projects and hardware producers writing open drivers, enlowering the effort in writing and mantaining a driver.
Michele
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines
<sorry for the direct reply>
makes sense, but are you sure having distros like Debian, enterprise products from redhat etc using the same 6months release for their stable versions does not translate in minor fragmentation on kernel development
I'm quite sure that there isn't significant fragmentation; all those distros in their maintenance generally only take patches that are already upstream (or they send them upstream during the maintenance) just to make sure that their long term costs don't go insane (eg for the $nextversion, the distros can just start clean because they know all bugfixes from maintenance versions are already in the new kernel.org kernel they get; not doing that is REALLY expensive so distros like to avoid that)
Quoted 1 line
and in benefits for every user?
you can't have it both ways; you can't be "new" and "old stable" at the same time.
Quoted 4 lines
. Another
advantage would be to benefit external projects and hardware producers writing open drivers, enlowering the effort in writing and mantaining a driver.
there is an even better model for those: Get it merged into kernel.org!
There is an even bigger deal here: even if you're not ready to get merged yet, staying on the same old version for 6 months is NOT going to help you. In fact it's worse: it is 10x easier to deal with 6 small steps of 1 month than to deal with 1 big step of 6 months.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 28 lines · Arjan van de Ven
Quoted 7 lines
<sorry for the direct reply>
makes sense, but are you sure having distros like Debian, enterprise products from redhat etc using the same 6months release for their stable versions does not translate in minor fragmentation on kernel development
I'm quite sure that there isn't significant fragmentation; all those distros in their maintenance generally only take patches that are already upstream (or they send them upstream during the maintenance) just to make sure that their long term costs don't go insane (eg for the $nextversion, the distros can just start clean because they know all bugfixes from maintenance versions are already in the new kernel.org kernel they get; not doing that is REALLY expensive so distros like to avoid that)
Quoted 1 line
and in benefits for every user?
you can't have it both ways; you can't be "new" and "old stable" at the same time.
Quoted 4 lines
. Another
advantage would be to benefit external projects and hardware producers writing open drivers, enlowering the effort in writing and mantaining a driver.
Quoted 9 lines
there is an even better model for those: Get it merged into kernel.org!
There is an even bigger deal here: even if you're not ready to get merged yet, staying on the same old version for 6 months is NOT going to help you. In fact it's worse: it is 10x easier to deal with 6 small steps of 1 month than to deal with 1 big step of 6 months.
from the kernel.org point of view it does make sense but from users pov i think no. Users stuck with old drivers not actively mantained would benefit from this.
There are some open drivers wrote by hardware mantainers which will never get into kernel.org cause of code not following kernel style guides and so on. Yeah, you should not buy poorly supported hardware and use bad drivers but a lot of new users have poorly supported hardware and a "more stable than usual and at fixed dates" release could enlower the skills barrier in approaching linux.
Michele
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · M.
from the kernel.org point of view it does make sense but from users pov i think no. Users stuck with old drivers not actively mantained would benefit from this.
Any specific examples of this?
Quoted 6 lines
There are some open drivers wrote by hardware mantainers which will never get into kernel.org cause of code not following kernel style guides and so on. Yeah, you should not buy poorly supported hardware and use bad drivers but a lot of new users have poorly supported hardware and a "more stable than usual and at fixed dates" release could enlower the skills barrier in approaching linux.
The skills barrier has _nothing_ to do with the release cycles.
And if you want to get a driver into the main tree, that isn't being maintained, just get a piece of the hardware to a kernel developer, along with the driver and it will be maintained. I know I've made that offer many times in the past, and so has others.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to M.Quoted 16 lines
Quoted 7 lines
Quoted 6 lines
. Another
advantage would be to benefit external projects and hardware producers writing open drivers, enlowering the effort in writing and mantaining a driver.Quoted 9 lines
there is an even better model for those: Get it merged into kernel.org!
There is an even bigger deal here: even if you're not ready to get merged yet, staying on the same old version for 6 months is NOT going to help you. In fact it's worse: it is 10x easier to deal with 6 small steps of 1 month than to deal with 1 big step of 6 months.
Quoted 3 lines
from the kernel.org point of view it does make sense but from users pov i think no. Users stuck with old drivers not actively mantained would benefit from this.
actually no. since that only buys them a few months at most, and then you're entirely stuck again. And patching it up after 6 months is a lot harder than doing smaller steps of 1 month, especially for less experienced people.
Quoted 3 lines
There are some open drivers wrote by hardware mantainers which will never get into kernel.org cause of code not following kernel style guides and so on.
which ones did you have in mind?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · M.
if distros would align on those 6months versions those less experienced users would get 5 years support on those kernels.
no distro gives 5 years of support for a kernel done every 6 months; they start such projects more like every 18 to 24 months (SuSE used to do it a bit more frequently but it seems they also slowed this down).
Quoted 3 lines
example: redhat, suse and mandriva are releasing their new product using the latest 6months (or whatever) kernel; they are not going to patch it except for new filesystems or bugfixes because of the new dev
"except for" is a slipperly slope. And "except for bugfixes" would be wrong... those would be the ones that need to be in the kernel.org kernel. As well as new hardware support. At which point.. what is the difference? Where do 'features' stop and where do 'only needed bugfixes' begin?
Quoted 6 lines
model granting them all the needed new features; then, they start to
mantain this kernel for their customers (and they could do it in a collaborative way, thus mantaining the kernel.org kernel plus their separate patches) and every user of redhat, suse, mandriva and the kernel.org 6months kernel they are using would benefit from this and would get 5 years support on this kernel.
that's not practical though. And it's still no better from the regression point of view; those enterprise kernels undergo quite a bit of churn as well, but just very directed churn to the point that I doubt it would satisfy your target audience....
Quoted 1 line
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Arjan van de Ven
Quoted 3 lines · M.
if distros would align on those 6months versions those less experienced users would get 5 years support on those kernels.
no distro gives 5 years of support for a kernel done every 6 months; they start such projects more like every 18 to 24 months (SuSE used to do it a bit more frequently but it seems they also slowed this down).
SUSE end-user distros (SUSE LINUX <version>) are released every 6 months or so, and are supported for 24 months. Their "enterprise server" is supported for 60 months though, SLES 9 forked off 9.1.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 8 lines · Matthias Andree
Quoted 6 lines · Arjan van de Ven
Quoted 3 lines · M.
if distros would align on those 6months versions those less experienced users would get 5 years support on those kernels.
Quoted 7 lines
Quoted 3 lines
no distro gives 5 years of support for a kernel done every 6 months; they start such projects more like every 18 to 24 months (SuSE used to do it a bit more frequently but it seems they also slowed this down).
SUSE end-user distros (SUSE LINUX <version>) are released every 6 months or so, and are supported for 24 months. Their "enterprise server" is supported for 60 months though, SLES 9 forked off 9.1.
sure.. but they don't add new hw support really, and I'd not be surprised if they rebase to a newer upstream kernel after a while. I know we did that for RHL, eg RHL 7.(Y-1) got the kernel of RHL7.Y after RHL7.Y was released, not only to keep the maintenance down, but more so to get all the bugfixes and hardware support out to customers.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Arjan, responding to Matthias
Quoted 6 lines
Quoted 3 lines
SUSE end-user distros (SUSE LINUX <version>) are released every 6 months or so, and are supported for 24 months. Their "enterprise server" is supported for 60 months though, SLES 9 forked off 9.1.
sure.. but they don't add new hw support really, and I'd not be surprised if they rebase to a newer upstream kernel after a while.
They will start a new enterprise release, off a new base, every so often, and call the next one SLES 10. But SLES 9 will continue to be supported, off its current kernel.org base, for an extended period of time.
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · M.
Quoted 7 lines · Arjan van de Ven
Quoted 2 lines · M.
if distros would align on those 6months versions those less experienced users would get 5 years support on those kernels.
no distro gives 5 years of support for a kernel done every 6 months; they start such projects more like every 18 to 24 months (SuSE used to do it a bit more frequently but it seems they also slowed this down).
Quoted 5 lines
yeah but I would mean if there's a 6months release cycle like GNOME & co. there would be more opportunities in different distros using the same kernel like those distros do with GNOME & co. If they use the same 'current' 6months kernel available in the 18/24 time window this will lead to unified base kernel for every distro and those distro could mantain it for years
The kernel is unlike GNOME in so many different ways, there's just no way to compare their development cycles.
People remember, the kernel evolves organically. We don't know what's going to be in the next 2 kernel releases just because we don't know what's going to show up, and what hardware is going to be released, and what kind of problems people are going to have, and what kind of proposed patches are going to work out.
The way the kernel is developed is _so_ different from any traditional software development process is defined. So for people to try to put traditional requirements on the kernel (6 month cycles, etc.) is just not realistic.
And please for everyone wanting to go with a stable series like is being proposed, go read the thread a while ago on this list that caused the creation of the -stable tree. In it lots of people who know what they are talking about discuss the difficulties of doing a "bug fix only" tree, and other such things. Out of that discussion came the very restrictive guidelines that are described in Documentation/stable_kernel_rules.txt. To try to do more than what is defined there, without lots of money and man-power behind you, is a quick trip to madness...
Best of luck to you all,
greg k-h
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · M.
Quoted 4 lines
The way the kernel is developed is _so_ different from any traditional software development process is defined. So for people to try to put traditional requirements on the kernel (6 month cycles, etc.) is just not realistic.
Mhhh BSDs and MacOSX kernel are developed without taking "the unknown" into
account: planned releases and bla blah and they dont miss features. Yeah linux is faster, but there could be a middle point between strict release cycles and "ok let's put it in cause it's going to make something run faster"
MacOSX is developed this way? I think you will find a lot of Apple engineers disagree with you...
And BSD is also quite different than Linux in many different ways, the development community being one of these differences. And that one difference makes a lot of difference.
Quoted 21 lines
Quoted 9 lines
And please for everyone wanting to go with a stable series like is being proposed, go read the thread a while ago on this list that caused the creation of the -stable tree. In it lots of people who know what they are talking about discuss the difficulties of doing a "bug fix only" tree, and other such things. Out of that discussion came the very restrictive guidelines that are described in
Documentation/stable_kernel_rules.txt. To try to do more than what is defined there, without lots of money and man-power behind you, is a quick trip to madness...The proposal was in fact to come out with a 2.6.X release every 6 months trying to align every distro on it and to "get" their man-power and money as a side effect. Maybe i'm not sufficiently good with english to let you all understand clearly but the proposal was to do 2/3/4 releases the normal/current style, even adding new and previously unknown features/patches/whatever and to do the last release before the next 2.6.Xwith only bugfix and stabilization in mind; If you think over it it's the
same approach of every release:
Quoted 5 lines
- patches get in until -rc;
- 2 weeks bugfix only;
- release;but applied to a 6months timeline.
That will not work. Again, go back and read that thread. We seeing this shorter development cycle get backed up even when it streaches to 2 months. For it to go to 6 months would be madness.
If you don't understand why I say this, please go look at the different developer trees that start accumilating patches during this "bugfix only" timeframe.
Quoted 3 lines
It's not a -stable/strict/specifics-based tree but a way to align everyone to the same kernel version and to get stabilization and maintenance as a side effect.
And you believe that the enterprise distros will some how flock to this kernel release instead? Why would they? What would it gain them?
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 1 line · Greg KH
On Sun, Dec 04, 2005 at 04:24:36PM +0100, M. wrote:
[...]
Quoted 9 lines
Quoted 6 lines
yeah but I would mean if there's a 6months release cycle like GNOME & co. there would be more opportunities in different distros using the same kernel like those distros do with GNOME & co. If they use the same 'current' 6months kernel available in the 18/24 time window this will lead to unified base kernel for every distro and those distro could mantain it for years
The kernel is unlike GNOME in so many different ways, there's just no way to compare their development cycles.
Gnome is a /collection/ of (mostly independent) programs, after a while what program+version survives a stress test is decreed to be part of version N + 1 to be released at the 6-month point; lather, rinse, repeat. In that sense it is much more like a distribution (which also have similar release cycles). The kernel is /one/ program, and large and complex to boot.
Quoted 5 lines
People remember, the kernel evolves organically. We don't know what's going to be in the next 2 kernel releases just because we don't know what's going to show up, and what hardware is going to be released, and what kind of problems people are going to have, and what kind of proposed patches are going to work out.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Arjan van de VenQuoted 17 lines · Arjan van de Ven
Quoted 2 lines · M.
if distros would align on those 6months versions those less experienced users would get 5 years support on those kernels.
no distro gives 5 years of support for a kernel done every 6 months; they start such projects more like every 18 to 24 months (SuSE used to do it a bit more frequently but it seems they also slowed this down).
Quoted 3 lines
example: redhat, suse and mandriva are releasing their new product using the latest 6months (or whatever) kernel; they are not going to patch it except for new filesystems or bugfixes because of the new dev
Quoted 5 lines
"except for" is a slipperly slope. And "except for bugfixes" would be wrong... those would be the ones that need to be in the kernel.org kernel. As well as new hardware support. At which point.. what is the difference? Where do 'features' stop and where do 'only needed bugfixes' begin?
Given the examples of 2.2 and 2.4 ongoing low level maintenence, I think that's a poor objection, a stable series (in the old sense) needs one maintainer to make the decisions on what goings in, and typically people will do the actualy work cooperating with the primary maintainer.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to M.Quoted 4 lines · M.
makes sense, but are you sure having distros like Debian, enterprise products from redhat etc using the same 6months release for their stable versions does not translate in minor fragmentation on kernel development and in benefits for every user?
It hasn't so far from my viewpoint. Do you think it has?
Quoted 7 lines
Under this light i think a 6months cycle starts to mean something when stable distros gets older and older (debian and redhat enterprise are released every 18/24 months) and developers and who wants bleeding edge features can always use Fedora, openSUSE, Gentoo etc. Another advantage would be to benefit external projects and hardware producers writing open drivers, enlowering the effort in writing and mantaining a driver.
Drivers belong in the main kernel.org kernel tree. See Documentation/stable-api-nonsense.txt for why this is so, and Documentation/HOWTO for how to get this accomplished. It is explained in great detail there. If you have further questions about this, please let us know.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KH* Greg KH:
Quoted 8 lines
Quoted 3 lines
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
If you are a user that wants this kind of support, then use a distro that can handle this. Obvious examples that come to mind are both Debian and Gentoo and Fedora and OpenSuSE, and I'm sure there are others.
IIRC, Gentoo ignores some kinds of security bugs so that the task remains manageable. Debian, in contrast, hasn't released a kernel update for its stable distribution since June (but unstable and even testing is in surprisingly good shape).
Maybe the real vendor kernels are better. Without CVE-based bug tracking on their part, it is hard to tell, though. 8-)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Florian Weimer
* Greg KH:
Quoted 4 lines
Quoted 3 lines
Yes but not home users with relatively new/bleeding edge hardware or small projects writing for example a wifi driver or a security patch or whatever without full time commitment to tracking kernel changes.
Quoted 7 lines
Quoted 4 lines
If you are a user that wants this kind of support, then use a distro that can handle this. Obvious examples that come to mind are both Debian and Gentoo and Fedora and OpenSuSE, and I'm sure there are others.
IIRC, Gentoo ignores some kinds of security bugs so that the task remains manageable.
Do you have specific details about this? I know the Gentoo kernel team is currently revamping the way they handle their security updates, as it is known to need some work. I'm sure they would be glad for input into this process.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 9 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
I don't get the point where the advantage is when every distribution creates it's own stable branches.
AFAIR one of the reasons for the current 2.6 development model was to reduce the amount of feature patches distributions ship by offering an ftp.kernel.org kernel that gets new features early.
What's wrong with offering an unified branch with few regressions for both users and distributions? It's not that every distribution will use it, but as soon as one or two distributions are using it the amount of extra work for maintaining the branch should become pretty low.
Quoted 3 lines
thanks,
greg k-h
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Adrian Bunk
Quoted 4 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
Quoted 8 lines
Quoted 5 lines
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
I don't get the point where the advantage is when every distribution creates it's own stable branches.
They only do so because they are on different release cycles.
Quoted 3 lines
AFAIR one of the reasons for the current 2.6 development model was to reduce the amount of feature patches distributions ship by offering an ftp.kernel.org kernel that gets new features early.
Sure, that's one of the reasons. But not the only one by far (I have a whole list somewhere, I'm sure it's in the archives...)
Quoted 4 lines
What's wrong with offering an unified branch with few regressions for both users and distributions? It's not that every distribution will use it, but as soon as one or two distributions are using it the amount of extra work for maintaining the branch should become pretty low.
"pretty low"? hahahahaha. As Arjan has said, the time and energy to do this for a long period of time is huge. If I were you, I would listen to the people who have and do maintain these kinds of kernels, it's not a simple job by any means.
But by all means, if you want to try to do this, please do. I wish you good luck.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 2 lines · * Adrian Bunk ([email protected]) wrote:
I don't get the point where the advantage is when every distribution creates it's own stable branches.
They often start from a different base.
Quoted 8 lines
AFAIR one of the reasons for the current 2.6 development model was to reduce the amount of feature patches distributions ship by offering an ftp.kernel.org kernel that gets new features early.
What's wrong with offering an unified branch with few regressions for both users and distributions? It's not that every distribution will use it, but as soon as one or two distributions are using it the amount of extra work for maintaining the branch should become pretty low.
Backporting is real work, and can introduce instabilities of its own. If the goal is to stop breaking userspace ABI, there's no guarantee this will be done via backporting w/out careful inspection, esp. for sysfs and proc entries. More to the point, breaking userspace (I'm not talking about deprecated features) should stop upstream, not only in some frozen branch. If the goal is to make sure old kernels have security fixes, which old kernel branch do you follow, the numbers will only grow. Distros are in a position to look at current -stable updates and see if security fixes are relevant. About the only thing I think is helpful in this case is perhaps one extra -stable cycle on the last branch when newest branch is released (basically flush the queue). That much I'm willing to do in -stable.
thanks,
-chris
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Chris Wright
relevant. About the only thing I think is helpful in this case is perhaps one extra -stable cycle on the last branch when newest branch is released (basically flush the queue). That much I'm willing to do in -stable.
Yay rah cool!
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
On 6 Dec 2005, Rob Landley moaned:
Quoted 6 lines · Chris Wright
Quoted 3 lines
relevant. About the only thing I think is helpful in this case is perhaps one extra -stable cycle on the last branch when newest branch is released (basically flush the queue). That much I'm willing to do in -stable.
Yay rah cool!
Seconded (thirded?), this is a very good idea (and as it's just a queue flush is probably quite easy to do).
That way those of us who are paranoid can upgrade our experimental boxes immediately, apply the latest -stable to the non-experimental boxes, and then cautiously upgrade those boxes when the experimental ones seem to be working OK. Currently whenever there's a non-stable kernel rev I'm filled with trepidation: do I upgrade the stable boxes and risk instability, or leave them as they are and risk insecurity?
Signature · 2 lines
`Y'know, London's nice at this time of year. If you like your cities freezing cold and full of surly gits.' --- David Damerell
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 5 lines
What's wrong with offering an unified branch with few regressions for both users and distributions? It's not that every distribution will use it, but as soon as one or two distributions are using it the amount of extra work for maintaining the branch should become pretty low.
the problem is simple: distributions will NOT use it. They can't, they need the newer HW support and the new features. The only difference is that you basically added just another distro branch. If you knew how many people it takes a distro to run such an old tree you'd be scared. (you need to include the QA people as well in this)
And distros hardly add hw support (the only hw support the enterprise distros add is contained to like 5 or 10 drivers of "enterprise" stuff, well testable and often validated by the vendor of the hw; and even then there are regressions regularly)... for your branch you target a different audience that does want a lot broader new HW support.
And then there's the bugfixes.. those tend to have regressions too, especially if you move them to a different context than they originally came from.
I'm not saying that you couldn't or shouldn't do this, I'm just saying that I think it'll be a LOT more work than you think, and that the gain is relatively minor. Especially since the main branch needs to sort the compatibility item ANYWAY.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian Bunk* Adrian Bunk:
Quoted 2 lines
I don't get the point where the advantage is when every distribution creates it's own stable branches.
Different vendors have different needs WRT proprietary drivers, experimental file systems, network stack tweaks. Their release cycles aren't synchronized, so it's not clear at which point you can make sorely needed architectural changes in a stable kernel series (for example, to fix some egregious performance issues, or complicated security issues).
Quoted 2 lines
What's wrong with offering an unified branch with few regressions for both users and distributions?
One user's regression is another's bug fix. And where do those regressions come from if you don't make any changes in functionality? 8-)
Quoted 3 lines
It's not that every distribution will use
it, but as soon as one or two distributions are using it the amount of extra work for maintaining the branch should become pretty low.
Maybe, but I don't see why a vendor should give up its kernel branding.
You mentioned security issues in your initial post. I think it would help immensely if security bugs would be documented properly (affected versions, configuration requirements, attack range, loss type etc.) when the bug is fixed, by someone who is familiar with the code. (Currently, this information is scraped together mostly by security folks, sometimes after considerable time has passed.) Having a central repository with this kind of information would enable vendors and not-quite-vendors (people who have their own set of kernels for their machines) to address more vulnerabilties promptly, including less critical ones.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Florian Weimer <[email protected]> wrote:
[...]
Quoted 10 lines
You mentioned security issues in your initial post. I think it would help immensely if security bugs would be documented properly (affected versions, configuration requirements, attack range, loss type etc.) when the bug is fixed, by someone who is familiar with the code. (Currently, this information is scraped together mostly by security folks, sometimes after considerable time has passed.) Having a central repository with this kind of information would enable vendors and not-quite-vendors (people who have their own set of kernels for their machines) to address more vulnerabilties promptly, including less critical ones.
I've fixed bugs which turned out to be security vulnerabilities. And I didn't know (or even care much) at the time. Finding out if some random bug has security implications, and exactly which ones/how much of a risk they pose is normally /much/ harder than to fix the bugs. And rather pointless, after the fix is in.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Horst von Brand
Quoted 10 lines
You mentioned security issues in your initial post. I think it would help immensely if security bugs would be documented properly (affected versions, configuration requirements, attack range, loss type etc.) when the bug is fixed, by someone who is familiar with the code. (Currently, this information is scraped together mostly by security folks, sometimes after considerable time has passed.) Having a central repository with this kind of information would enable vendors and not-quite-vendors (people who have their own set of kernels for their machines) to address more vulnerabilties promptly, including less critical ones.
Quoted 5 lines
I've fixed bugs which turned out to be security vulnerabilities. And I didn't know (or even care much) at the time. Finding out if some random bug has security implications, and exactly which ones/how much of a risk they pose is normally /much/ harder than to fix the bugs. And rather pointless, after the fix is in.
I believe everyone who maintains a nontrivial piece of software has experienced a situation where a bug fix addressed a bug that could actually be exploited and that wasn't clear at the time.
Calling this "pointless" after the fix is in leaves people in danger unaware, unless it happens on a branch where every user can be expected to update because only tested fixes are merged. As this isn't the case for the kernel, but everyone moves on at will, doesn't care if a previous bug fix is exploitable and whatnot, the Linux kernel's security is essentially nonexistent, and expecting downstream QA teams to handle this is just ridiculous for many reasons already mentioned.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Horst von Brand* Horst von Brand:
Quoted 11 lines
Quoted 10 lines
You mentioned security issues in your initial post. I think it would help immensely if security bugs would be documented properly (affected versions, configuration requirements, attack range, loss type etc.) when the bug is fixed, by someone who is familiar with the code. (Currently, this information is scraped together mostly by security folks, sometimes after considerable time has passed.) Having a central repository with this kind of information would enable vendors and not-quite-vendors (people who have their own set of kernels for their machines) to address more vulnerabilties promptly, including less critical ones.
Quoted 4 lines
I've fixed bugs which turned out to be security vulnerabilities. And I didn't know (or even care much) at the time. Finding out if some random bug has security implications, and exactly which ones/how much of a risk they pose is normally /much/ harder than to fix the bugs.
I know, it happens all the time: vulnerabilities are fixed because they are bugs, and not because they are vulnerabilities. It's unfortunate if people are unnecessarily exposed to the vulnerability (because they don't know about it and don't apply the fix as a result), but it's better than carrying around the bug indefinitely.
But if there's considerable evidence that you might have fixed a security bug, preserving this information (and other bits that are immediately obvious to you as a developer, but not necessarily who reviews the issue) seems worthwhile. Maybe you don't want to put it into the public commit message, but forwarding what you have to some trusted group of volunteers would make sense. The volunteers would distill the information, add more data and assign a CVE if necessary, and declassify the information as soon as the public is ready (in the form of a short security advisory, like the ones you see for most applications).
Does this sound too far-fetched? Why don't you think this would be a valuable service to all users, vanilla kernels or not?
Quoted 1 line
And rather pointless, after the fix is in.
It doesn't matter much if the fix is in the kernel.org tree, when I'm supposed to use vendor kernels. 8-)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 34 lines · Florian Weimer
* Horst von Brand:
Quoted 11 lines
Quoted 10 lines
You mentioned security issues in your initial post. I think it would help immensely if security bugs would be documented properly (affected versions, configuration requirements, attack range, loss type etc.) when the bug is fixed, by someone who is familiar with the code. (Currently, this information is scraped together mostly by security folks, sometimes after considerable time has passed.) Having a central repository with this kind of information would enable vendors and not-quite-vendors (people who have their own set of kernels for their machines) to address more vulnerabilties promptly, including less critical ones.
Quoted 4 lines
I've fixed bugs which turned out to be security vulnerabilities. And I didn't know (or even care much) at the time. Finding out if some random bug has security implications, and exactly which ones/how much of a risk they pose is normally /much/ harder than to fix the bugs.
I know, it happens all the time: vulnerabilities are fixed because they are bugs, and not because they are vulnerabilities. It's unfortunate if people are unnecessarily exposed to the vulnerability (because they don't know about it and don't apply the fix as a result), but it's better than carrying around the bug indefinitely.
But if there's considerable evidence that you might have fixed a security bug, preserving this information (and other bits that are immediately obvious to you as a developer, but not necessarily who reviews the issue) seems worthwhile. Maybe you don't want to put it into the public commit message, but forwarding what you have to some trusted group of volunteers would make sense. The volunteers would distill the information, add more data and assign a CVE if necessary, and declassify the information as soon as the public is ready (in the form of a short security advisory, like the ones you see for most applications).
Quoted 2 lines
Does this sound too far-fetched? Why don't you think this would be a valuable service to all users, vanilla kernels or not?
But, as you'll recall, ALan Cox fixed a couple of major security things about 2 years ago, and because of the DMCA, those patches weren't commented at all. Apparently the fix could only be determined to be correct by violating the DMCA, and he was very pointed in his comments re the DMCA at the time.
So keeping good records might/could be a double edged sword.
Quoted 9 lines
Quoted 1 line
And rather pointless, after the fix is in.
It doesn't matter much if the fix is in the kernel.org tree, when I'm supposed to use vendor kernels. 8-)
-
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/
Signature · 8 lines
Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.36% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 10 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
Yes, I know this is what's done with the "enterprise" distro kernels. Perhaps I should have phrased it "Why can't this job just stay with vendors".
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Jesper Juhl
Quoted 8 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
Quoted 6 lines
Quoted 2 lines
If people/customers want stability, they already have this option.
Yes, I know this is what's done with the "enterprise" distro kernels. Perhaps I should have phrased it "Why can't this job just stay with vendors".
Because this is just shifting the blame for and work to make up for the upstream not providing a stable tree on somebody else and prescinds from the fact that many people are apparently unhappy with 2.6.X policies.
I cannot see a project issuing "stable releases" if every other developer bleats "let the distro snapshot and backport fixes on their own". This is exactly the point that turns away half of those who hadn't been scared away by the "Linux has no uniform userland" problem yet.
2.6.0 is now nearly two years old, perhaps the current discussions mean that 2.7/2.8 are long overdue - some people feel the need for more radical code changes, which are 2.7 stuff.
The problem is the upstream breaking backwards compatibility for no good reason. This can sometimes be a genuine unintended regression (aka. bug), but quite often this is deliberate breakage because someone wants to get rid of cruft. While the motivation is sound, breaking between 2.6.N and 2.6.M must stop.
One of the ideas of the new development style and versioning scheme was to have 2.6 progress faster than 2.3 or 2.5, and to have shorter release cycles. It was found to introduce way too much breakage. Linus's relatively new policy "merge new stuff only during the fortnight after release, then fix up" is a concession to these observations that too many things break if there is a constant influx of feature changes.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Matthias Andree
The problem is the upstream breaking backwards compatibility for no good reason. This can sometimes be a genuine unintended regression (aka. bug), but quite often this is deliberate breakage because someone wants to get rid of cruft. While the motivation is sound, breaking between 2.6.N and 2.6.M must stop.
What are we breaking that people are complaining so much about? Specifics please.
And if you bring up udev, please see my previous comments in this thread about that issue.
It isn't userspace stuff that is breaking, as applications built on 2.2 still work just fine here on 2.6 for me.
Yes we break in-kernel apis, all the time, that's fine. See Documentation/stable-api-nonsense.txt for details about why we do that.
So again, specifics please?
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Hi Greg,
I've been following most of this thread but did hot take the time to jump in.
Quoted 9 lines · Greg KH
Quoted 5 lines · Matthias Andree
The problem is the upstream breaking backwards compatibility for no good reason. This can sometimes be a genuine unintended regression (aka. bug), but quite often this is deliberate breakage because someone wants to get rid of cruft. While the motivation is sound, breaking between 2.6.N and 2.6.M must stop.
What are we breaking that people are complaining so much about? Specifics please.
Speaking for myself, I will not be complaining about specific things which break, but I'll explain my point of view on the real problem.
The kernel has entered a permanent development phase, with some versions more stable/usable than others. You and Chris do a wonderful job at producing stable versions. I know how difficult it is, for doing the same in 2.4 (and 2.4 moves slower than 2.6).
However, the problem is that you stop maintaining old versions and quickly switch to new ones when a new kernel comes up. I know it's not easy, and may be terribly more difficult to maintain several versions in a development kernel than in a stable kernel. But imagine the users' position : they run 2.6.14.3 which finally fixes all their problems. Then they get a new problem, but 2.6.15 comes out. There will not be any other 2.6.14, so they have the choice of staying to 2.6.14.3 or jumping to fresh new and barely tested 2.6.15.
People have been surprized that I still maintain several old versions of 2.4 at once, but I've received lots of "thank you" emails from people who still relied on them for a particular tree which does not evolve as fast as mainline. And 2.4 is easier to follow than 2.6.
What I think should be done is to still maintain older 2.6 (eg: 2, 3 or 4 previous releases) so that people will have the time to switch to a new one. And I think that what Adrian wants to do would be useful *only* if he proceeds that way.
Maybe you should just join forces, eg Chris and you to catch new patches, and Adrian to merge them to older kernels ? Every software maker always supports a few older releases for the people who need to stay on something stable, and it is clearly what is missing now in 2.6.
Also, I think differently from Adrian. He wants to backport all new drivers and new features, while I think that they are the most sensible parts and the one which bring the more changes to the kernel. In fact, we should *only* maintain security and critical fixes on older releases. People in the need of a new driver must upgrade for this. This is the difference between staying on an old thing because you don't need to upgrade and switching to a new one because you need this new shiny feature. It follows the "if it ain't broke, don't fix it" rule. Users will never excuse you for breaking their working kernels by adding something they don't use.
I would have liked to help in this area (I even discussed about maintaining a 2.6-stable a long time ago) but I don't have enough time for this. 2.4 is already time-consuming.
Regards,
Willy
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Willy Tarreau
However, the problem is that you stop maintaining old versions and quickly switch to new ones when a new kernel comes up. I know it's not easy, and may be terribly more difficult to maintain several versions in a development kernel than in a stable kernel. But imagine the users' position : they run 2.6.14.3 which finally fixes all their problems. Then they get a new problem, but 2.6.15 comes out. There will not be any other 2.6.14, so they have the choice of staying to 2.6.14.3 or jumping to fresh new and barely tested 2.6.15.
"Regression" as the threat of updating. That was the starting point :)
I believe the reason to abandon the previous "stable" branchlet was the assumption that the new kernel had all fixes from the previous "stable" merged, i. e. every patch between 2.6.14 and 2.6.14.3 would become part of 2.6.15 (or the underlying problem addressed by a patch were resolved some other way).
Quoted 4 lines
What I think should be done is to still maintain older 2.6 (eg: 2, 3 or 4 previous releases) so that people will have the time to switch to a new one. And I think that what Adrian wants to do would be useful *only* if he proceeds that way.
Perhaps a fixed number of releases doesn't cut it. Perhaps a fixed time neither. If the changes betweeen two subsequent releases is low, one or more extra versions come for free, but if lots of changes go in all over the map, it's going to be a royal pain.
It ultimately boils down to the question: how far^Wfast the upstream wants to run away^W^Wprogress from its previous release.
Quoted 6 lines
Also, I think differently from Adrian. He wants to backport all new drivers and new features, while I think that they are the most sensible parts and the one which bring the more changes to the kernel. In fact, we should *only* maintain security and critical fixes on older releases. People in the need of a new driver must upgrade for this. This is the
I think there is no such thing as The Single One New Driver[tm]. Some are quite intrusive, some aren't. Sometimes the new driver works with older kernels (if the driver is self-contained, for instance just a dozen new lines of code in an existing driver), sometimes not (because midlayer or core changes are required to support the new driver).
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Willy TarreauQuoted 10 lines · Willy Tarreau
What I think should be done is to still maintain older 2.6 (eg: 2, 3 or 4 previous releases) so that people will have the time to switch to a new one. And I think that what Adrian wants to do would be useful *only* if he proceeds that way.
Maybe you should just join forces, eg Chris and you to catch new patches, and Adrian to merge them to older kernels ? Every software maker always supports a few older releases for the people who need to stay on something stable, and it is clearly what is missing now in 2.6.
Well, this is probably the most useful suggestion so far. The kernel is free land; if you or someone else wants to maintain the upcoming 2.6.16 "forever", and backport fixes or selected features, by all means, do it. Define your policy, set up a tree, and off you go.
If Adrian will maintain it, it'll for sure be the most static kernel ever.
This won't impact the Linux kernel, which will just continue to run its course. The kernel process as a whole doesn't need to change; just someone needs to do the grunt work.
If your kernel is wildly successful and adopted by users as well as distributions, you'll be very happy and tell us 'told ya so!'. If not, no harm will be done either, and you'll have the kernel you want for your own purposes.
Be aware however that this is a very painful job. Trust me, I've been involved with the receiving end of maintaining such a kernel for SLES for a couple of releases. ;-)
Which is exactly the point: it's so painful that for this, people want to be paid, and don't like doing it in their spare time. You may maintain it for 6 months, sure, which will be less painful than maintaining it for 5, 7 years, but when you rebase, you'll still put your users into the dependency hell, and they won't have tested the intermediate releases... Ouch. Not to mention that not every backported fix is trivial to do.
Anyway, good luck to you.
The current 2.6.x.y-stable series is quite sane, because they are essentially just fixing very critical bugs in very recent kernels, with little back porting effort.
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 42 lines · Lars Marowsky-Bree
Quoted 10 lines · Willy Tarreau
What I think should be done is to still maintain older 2.6 (eg: 2, 3 or 4 previous releases) so that people will have the time to switch to a new one. And I think that what Adrian wants to do would be useful *only* if he proceeds that way.
Maybe you should just join forces, eg Chris and you to catch new patches, and Adrian to merge them to older kernels ? Every software maker always supports a few older releases for the people who need to stay on something stable, and it is clearly what is missing now in 2.6.
Well, this is probably the most useful suggestion so far. The kernel is free land; if you or someone else wants to maintain the upcoming 2.6.16 "forever", and backport fixes or selected features, by all means, do it. Define your policy, set up a tree, and off you go.
If Adrian will maintain it, it'll for sure be the most static kernel ever.
This won't impact the Linux kernel, which will just continue to run its course. The kernel process as a whole doesn't need to change; just someone needs to do the grunt work.
If your kernel is wildly successful and adopted by users as well as distributions, you'll be very happy and tell us 'told ya so!'. If not, no harm will be done either, and you'll have the kernel you want for your own purposes.
Be aware however that this is a very painful job. Trust me, I've been involved with the receiving end of maintaining such a kernel for SLES for a couple of releases. ;-)
Which is exactly the point: it's so painful that for this, people want to be paid, and don't like doing it in their spare time. You may maintain it for 6 months, sure, which will be less painful than maintaining it for 5, 7 years, but when you rebase, you'll still put your users into the dependency hell, and they won't have tested the intermediate releases... Ouch. Not to mention that not every backported fix is trivial to do.
Quoted 5 lines
Anyway, good luck to you.
The current 2.6.x.y-stable series is quite sane, because they are essentially just fixing very critical bugs in very recent kernels, with little back porting effort.
I agree it is sane. The problem is that it does not exist for long enough. When you have 2.6.14.X working perfectly and you need a fix for a newly discovered security fix which only exists in 2.6.15.Y, then you have to leave 2.6.14 and enter 2.6.15. That is the problem, because for just a fix, you change megabytes of source code which will bring their equivalent in bugs.
Regards,
willy
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Willy Tarreau
Quoted 5 lines
Anyway, good luck to you.
The current 2.6.x.y-stable series is quite sane, because they are essentially just fixing very critical bugs in very recent kernels, with little back porting effort.
Quoted 6 lines
I agree it is sane. The problem is that it does not exist for long enough. When you have 2.6.14.X working perfectly and you need a fix for a newly discovered security fix which only exists in 2.6.15.Y, then you have to leave 2.6.14 and enter 2.6.15. That is the problem, because for just a fix, you change megabytes of source code which will bring their equivalent in bugs.
As I said, please, go on maintaining a release for a longer period of time.
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 15 lines · Lars Marowsky-Bree
Quoted 6 lines · Willy Tarreau
Quoted 5 lines
Anyway, good luck to you.
The current 2.6.x.y-stable series is quite sane, because they are essentially just fixing very critical bugs in very recent kernels, with little back porting effort.
Quoted 6 lines
I agree it is sane. The problem is that it does not exist for long enough. When you have 2.6.14.X working perfectly and you need a fix for a newly discovered security fix which only exists in 2.6.15.Y, then you have to leave 2.6.14 and enter 2.6.15. That is the problem, because for just a fix, you change megabytes of source code which will bring their equivalent in bugs.
Quoted 2 lines
As I said, please, go on maintaining a release for a longer period of time.
As I said, I know this is difficult, I already do this for 2.4 and 2.4 is not moving fast. But what Adrian wants to do might be far more difficult. That's why I suggest him to do "only" this, he will have less work and get a lot of happy users.
Regards,
Willy
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lars Marowsky-BreeQuoted 2 lines · In article <[email protected]> you wrote:
As I said, please, go on maintaining a release for a longer period of time.
On the other hand:
Since it is such a ugly big boring and complicated task, why do you still think it can be done by volunteers? (or why will commercial distributions have the power to pay for this in the long run)
I think this is exactly the reason why it cannot be done in parallel by volunteers without support from all of the contributors. With an official stable trunk it attrackts more backports. It is clear where the security fixes must happen, etc.
We used to have this back in the 2.4 days with longer release cycles. However I am not sure if that was better or worse.
Gruss
Bernd
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines
We used to have this back in the 2.4 days with longer release cycles. However I am not sure if that was better or worse.
2.4 also had its fair share of regressions. Just that people by now have forgotten about those ;)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Willy TarreauQuoted 5 lines · Willy Tarreau
Maybe you should just join forces, eg Chris and you to catch new patches, and Adrian to merge them to older kernels ? Every software maker always supports a few older releases for the people who need to stay on something stable, and it is clearly what is missing now in 2.6.
I don't think people realize that the -stable series only contains patches that other people send us. For the most part, Chris and I aren't going out there and activly writing up fixes for some of these issues, as we both don't have the time and energy to do this.
But if someone wants to start sending us more patches that do this, we will be glad to incorporate them. And as Chris said, we will be glad to release an extra release for the last kernel if we have pending patches.
And also, anyone else can easily take over maintaining these kernel branches. The git trees are public, as is our stable patch queue. So if anyone wants to maintain older kernels, it is quite easy to start the process.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines · Greg KH
I don't think people realize that the -stable series only contains patches that other people send us. For the most part, Chris and I aren't going out there and activly writing up fixes for some of these issues, as we both don't have the time and energy to do this.
The -stable series was a good idea, and thanks for doing it. Adrian's idea is a natural extension of what you started.
Quoted 4 lines
And also, anyone else can easily take over maintaining these kernel branches. The git trees are public, as is our stable patch queue. So if anyone wants to maintain older kernels, it is quite easy to start the process.
So if Adrian wants to begin where -stable ends, there is no reason for people to oppose his efforts.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · John Kelly
Quoted 4 lines · Greg KH
I don't think people realize that the -stable series only contains patches that other people send us. For the most part, Chris and I aren't going out there and activly writing up fixes for some of these issues, as we both don't have the time and energy to do this.
The -stable series was a good idea, and thanks for doing it. Adrian's idea is a natural extension of what you started.
Quoted 7 lines
Quoted 4 lines
And also, anyone else can easily take over maintaining these kernel branches. The git trees are public, as is our stable patch queue. So if anyone wants to maintain older kernels, it is quite easy to start the process.
So if Adrian wants to begin where -stable ends, there is no reason for people to oppose his efforts.
I've read the whole thread, and I haven't seen anyone opposing my idea.
Most people in this thread who did or do maintain some kernel branch simply expressed that in their opinion my idea would be too much work for too few users...
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 8 lines · Adrian Bunk
Quoted 2 lines
So if Adrian wants to begin where -stable ends, there is no reason for people to oppose his efforts.
I've read the whole thread, and I haven't seen anyone opposing my idea.
Most people in this thread who did or do maintain some kernel branch simply expressed that in their opinion my idea would be too much work for too few users...
If you build it, will they come?
No one really knows. There is only one way to find out.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 13 lines · Greg KH
Quoted 5 lines · Matthias Andree
The problem is the upstream breaking backwards compatibility for no good reason. This can sometimes be a genuine unintended regression (aka. bug), but quite often this is deliberate breakage because someone wants to get rid of cruft. While the motivation is sound, breaking between 2.6.N and 2.6.M must stop.
What are we breaking that people are complaining so much about? Specifics please.
And if you bring up udev, please see my previous comments in this thread about that issue.
Quoted 7 lines
It isn't userspace stuff that is breaking, as applications built on 2.2 still work just fine here on 2.6 for me.
Yes we break in-kernel apis, all the time, that's fine. See
Documentation/stable-api-nonsense.txtfor details about why we do that.So again, specifics please?
It's the kernel-related userspace that is the problem (besides regressions that are simply bugs).
Be it the devfs removal, the requirement for a more recent wpa_supplicant package or my pending removal of the obsolete raw driver.
Quoted 3 lines
thanks,
greg k-h
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 17 lines · Adrian Bunk
Quoted 16 lines · Greg KH
Quoted 5 lines · Matthias Andree
The problem is the upstream breaking backwards compatibility for no good reason. This can sometimes be a genuine unintended regression (aka. bug), but quite often this is deliberate breakage because someone wants to get rid of cruft. While the motivation is sound, breaking between 2.6.N and 2.6.M must stop.
What are we breaking that people are complaining so much about? Specifics please.
And if you bring up udev, please see my previous comments in this thread about that issue.
It isn't userspace stuff that is breaking, as applications built on 2.2 still work just fine here on 2.6 for me.
Quoted 7 lines
Quoted 4 lines
Yes we break in-kernel apis, all the time, that's fine. See
Documentation/stable-api-nonsense.txtfor details about why we do that.So again, specifics please?
It's the kernel-related userspace that is the problem (besides regressions that are simply bugs).
Again, specifics please?
Quoted 3 lines
Be it the devfs removal, the requirement for a more recent
wpa_supplicantpackage or my pending removal of the obsolete raw driver.
devfs was documented for over a year that it would be removed. This after 2 year notice that it was going to be removed some time in the future. So for over 3 years people have known about this.
You have also notified people about the raw driver going away, what more can we do about this?
And there will always be a need for new package upgrades for some small subset of programs that are tightly tied to the kernel (like wpa_supplicant or alsa-libs, or even udev). But "normal" userspace applicatations should not break, and if they do, we want to know about it so we can fix it.
thanks,
greg k-h
Policy for reverting user ABI breaking patches was Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines · Greg KH
And there will always be a need for new package upgrades for some small subset of programs that are tightly tied to the kernel (like
wpa_supplicantor alsa-libs, or even udev). But "normal" userspace
Actually I don't necessarily agree on that. It's best to avoid breakage even for them. It has actually worked for a long time. In the early days of Linux there was frequent breakage like this but then in recent times the kernel has been very good at this for a long time (one exception was the module rewrite, but that was a single flag day). I have been running modern kernels on old distributions for a long time and it generally worked.
And if there is breakage of such kernel-near applications there should be an *extremly* good reason for this (and minor cleanup isn't such a reason). For example for the recent udev breakage imho the cleanup patch that caused this should have just been reverted. I know it's not possible to know such bad interactions in advance, but when they are known and there isn't an *extremly* good reason for it then the ABI breaking change should be reverted.
It would be good to have a policy like this: if an important program breaks due to a new kernel
[With important being fairly liberally defined as anything shipped in standard distros unless it's something exotic that does something stupid or is obviously broken. External kernel modules or /dev/mem access don't count.]
then the breakage needs to have an *extremly* good rationale (fixing security bugs etc.) and if there isn't one from the person who submitted the patch then it should be reverted.
-Andi
Re: Policy for reverting user ABI breaking patches was Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines · Andi Kleen
And if there is breakage of such kernel-near applications there should be an *extremly* good reason for this (and minor cleanup isn't such a reason). For example for the recent udev breakage imho the cleanup patch that caused this should have just been reverted.
It was not a cleanup patch, without it you could not get input events through netlink.
I wonder, since udev is fairly closely tied to the kernel, meybe it woudl be beneficial just to fold it in. This way we could keep compatibility with older kernels and rapidly roll out never stuff.
--
Dmitry
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KH* Greg KH:
Quoted 2 lines
What are we breaking that people are complaining so much about? Specifics please.
Drastic performance changes in certain pipe usage patterns. This was probably too early in the 2.6 series to count, though.
There might be some subtle changes in the netfilter/routing interaction which break user configurations, but this still being tracked down (and maybe the any behavior is fine because it's unspecified; hard to tell).
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Felipe Alfaro Solana
Quoted 4 lines
There might be some subtle changes in the netfilter/routing interaction which break user configurations, but this still being tracked down (and maybe the any behavior is fine because it's unspecified; hard to tell).
Yeah! For example, the first datagram triggering an IPSec SA is always lost (instead of being queued until the IPSec SA has been established).
Quoted 5 lines
For example, try pinging the IPSec SA peer for the very first time and the first ICMP datagram will always return "resource currently unavailable" and, of course, will get lost.
BTW this works perfectly under *BSD and Mac OS X.
Do the network kernel developers know about this issue? And if so, what have they said about it?
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
From: Greg KH <[email protected]>
Date: Tue, 6 Dec 2005 09:47:14 -0800
Quoted 10 lines · Felipe Alfaro Solana
Quoted 9 lines
Quoted 4 lines
There might be some subtle changes in the netfilter/routing interaction which break user configurations, but this still being tracked down (and maybe the any behavior is fine because it's unspecified; hard to tell).
Yeah! For example, the first datagram triggering an IPSec SA is always lost (instead of being queued until the IPSec SA has been established).
Quoted 8 lines
Quoted 5 lines
For example, try pinging the IPSec SA peer for the very first time and the first ICMP datagram will always return "resource currently unavailable" and, of course, will get lost.
BTW this works perfectly under *BSD and Mac OS X.
Do the network kernel developers know about this issue? And if so, what have they said about it?
It's on the TODO list, known problem with not an easy solution.
BTW, BSD doesn't do any better, the KAME BSD ipsec stack drops the initial datagram just like we do.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Florian WeimerQuoted 7 lines · Florian Weimer
* Greg KH:
Quoted 2 lines
What are we breaking that people are complaining so much about? Specifics please.
Drastic performance changes in certain pipe usage patterns. This was probably too early in the 2.6 series to count, though.
Where's the bug report?
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 9 lines · Greg KH
Quoted 2 lines · Jesper Juhl
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
If the kernel was stable (reliability wise - as in "not crashing") then you'd be perfectly right.
In the real world, however, admins currently need to pick out specific versions of the kernel for specific workloads (try running a large fileserver on anything but 2.6.11.11 for example - any earlier or later kernel will barf reliably. For web serving it's another kernel that's golden, I forgot which).
There are very very good reasons for offering a 'stable series' in plain source-tree form - lots of admins of real-world systems need this.
Adrian, I like the idea :)
Signature · 1 line
/ jakob
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Jakob Oestergaard
If the kernel was stable (reliability wise - as in "not crashing") then you'd be perfectly right.
But isn't it? :)
Quoted 4 lines
In the real world, however, admins currently need to pick out specific versions of the kernel for specific workloads (try running a large fileserver on anything but 2.6.11.11 for example - any earlier or later kernel will barf reliably.
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
Quoted 1 line
For web serving it's another kernel that's golden, I forgot which).
That sounds very strange, the same kernel version should work just as well for all workloads. If not, it's a bug and should be fixed.
Quoted 2 lines
There are very very good reasons for offering a 'stable series' in plain source-tree form - lots of admins of real-world systems need this.
But it sounds like you will want different stable series depending on what kind of server you are running. And that will be even more work...
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Greg KH
Quoted 3 lines · Jakob Oestergaard
If the kernel was stable (reliability wise - as in "not crashing") then you'd be perfectly right.
But isn't it? :)
I like your sense of humor :)
Quoted 7 lines
Quoted 4 lines
In the real world, however, admins currently need to pick out specific versions of the kernel for specific workloads (try running a large fileserver on anything but 2.6.11.11 for example - any earlier or later kernel will barf reliably.
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
I don't expect to get it fixed. It's futile. It can get fixed in one version and broken two days later, and it seems the attitude is that that is just fine.
After a long long back-and-forth, 2.6.11 was fixed to the point where it could reliably serve files (at least on uniprocessor configurations - and in my setup I don't see problems on NUMA either, but as far as I know that's just me being lucky).
Right after that, someone thought it was a great idea to pry out the PCI subsystem and shovel in something else. Find, that's great for a development kernel, but for a kernel that's supposed to be stable it's just not something you can realistically do and expect things to work afterwards. And things broke - try mounting 10-20 XFS filesystems simultaneously on 2.6.14. Boom - PCI errors.
Now what? Do I as a user upgrade my production environment to the latest and greatest kernel experiment, hope that the problems can be fixed quickly, and hope that I don't lose too much data in the process? (remember I will have people unable to do their jobs whenever the file
server is down). Or do I stay on 2.6.11.11 which works on this
particular server?
I think I stay.
Quoted 5 lines
Quoted 2 lines
For web serving it's another kernel that's golden, I forgot which).
That sounds very strange, the same kernel version should work just as well for all workloads. If not, it's a bug and should be fixed.
Well... You have bugs in different places in different kernels. It's perfectly understandable that kernel A works for workload p and fails on workload q, where kernel B works for workload q and fails on p.
Quoted 6 lines
Quoted 3 lines
There are very very good reasons for offering a 'stable series' in plain source-tree form - lots of admins of real-world systems need this.
But it sounds like you will want different stable series depending on what kind of server you are running. And that will be even more work...
The idea would be to fix the actual bugs. After a while, one could have a kernel of higher quality with fewer bugs, making it a lot more likely that the *same* kernel tree could be used for both workloads A and B.
It's really very simple :)
Now, I'm just giving my oppinion as a user, and my advise as a developer
- I know how much it sucks to postpone new great cleanups or features, just because some policy says the current branch has to be 'stable'. But I also know how much it sucks to have users complain that a new feature broke their existing setup. That's not a problem for a kernel developer of course, because users don't pay for the service and the "if it breaks you get to keep the pieces" attitude can be defended. But as a user, it really really sucks, even if you get to keep the pieces.
I don't mean to be entirely negative - sure there are great things about the new development model. But there is a very significant downside for at least a group of users too.
My 0.02 Euro, for what it's worth.
Signature · 1 line
/ jakob
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Hi,
Quoted 2 lines · Greg KH
Quoted 2 lines
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
Quoted 3 lines · Jakob Oestergaard
I don't expect to get it fixed. It's futile. It can get fixed in one version and broken two days later, and it seems the attitude is that that is just fine.
I don't think anyone breaks things on purpose. Please feel free to report the bug as many times as necessary to get it fixed. You shouldn't be complaining if you're not doing your part.
Pekka
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Pekka Enberg
Hi,
Quoted 2 lines · Greg KH
Quoted 2 lines
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
Quoted 6 lines
Quoted 3 lines · Jakob Oestergaard
I don't expect to get it fixed. It's futile. It can get fixed in one version and broken two days later, and it seems the attitude is that that is just fine.
I don't think anyone breaks things on purpose.
Of course not, silly :)
But there's a difference between having a tree where you fix bugs and having a tree where you are very lax about major changes. By including major changes you (knowingly or not) risk breaking things, and things do break regularly.
Quoted 2 lines
Please feel free to
report the bug as many times as necessary to get it fixed.
Thank you :)
If it did not occur to you, then I was never in doubt of this. I tried to point out a problem in this approach - namely, that you will never end up with a stable tree if major changes (read; new bugs) go in as fast as old bugs are squashed.
You do get a tree that is evolving very quickly, and which is somewhat stable for most purposes. Whether or not that is good enough for everyone, was pretty much the topic of this thread as I understand it.
Quoted 2 lines
You
shouldn't be complaining if you're not doing your part.
I'm not complaining. I'm voicing my oppinion in a thread that discusses whether or not it would be a good idea to try and produce a stable tree.
I think it would be a good idea, and you're free to disagree.
Please read the thread if you're in doubt of the context of my comments :)
Signature · 1 line
/ jakob
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Jakob OestergaardQuoted 7 lines · Jakob Oestergaard
Quoted 6 lines · Greg KH
Quoted 4 lines · Jakob Oestergaard
In the real world, however, admins currently need to pick out specific versions of the kernel for specific workloads (try running a large fileserver on anything but 2.6.11.11 for example - any earlier or later kernel will barf reliably.
Quoted 6 lines
Quoted 2 lines
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
I don't expect to get it fixed. It's futile. It can get fixed in one version and broken two days later, and it seems the attitude is that that is just fine.
Huh? That is just not true at all. Please give us a bit more credit than that.
Quoted 11 lines
After a long long back-and-forth, 2.6.11 was fixed to the point where it could reliably serve files (at least on uniprocessor configurations - and in my setup I don't see problems on NUMA either, but as far as I know that's just me being lucky).
Right after that, someone thought it was a great idea to pry out the PCI subsystem and shovel in something else. Find, that's great for a development kernel, but for a kernel that's supposed to be stable it's just not something you can realistically do and expect things to work afterwards. And things broke - try mounting 10-20 XFS filesystems simultaneously on 2.6.14. Boom - PCI errors.
What PCI errors are you speaking of? We did that PCI work to fix a lot of other machines that were having problems. And yes, this did break some working machines, and we are very sorry about this. But in the future, changes to this area will not cause this to happen due to the changes made.
Please file a bug in bugzilla.kernel.org and let us know you are having problems. Otherwise we have no idea.
Quoted 3 lines
Now what? Do I as a user upgrade my production environment to the latest and greatest kernel experiment, hope that the problems can be fixed quickly, and hope that I don't lose too much data in the process?
No, if you rely on a production environment for your stuff, stick with a disto kernel which has been tested and is backed up by a company that will maintain it over time.
Quoted 5 lines
(remember I will have people unable to do their jobs whenever the file
server is down). Or do I stay on 2.6.11.11 which works on this
particular server?I think I stay.
As you wish.
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
There are very very good reasons for offering a 'stable series' in plain source-tree form - lots of admins of real-world systems need this.
But it sounds like you will want different stable series depending on what kind of server you are running. And that will be even more work...
The idea would be to fix the actual bugs. After a while, one could have a kernel of higher quality with fewer bugs, making it a lot more likely that the *same* kernel tree could be used for both workloads A and B.
It's really very simple :)
If you can point out the "actual bugs" yes. It sounds so simple from a theoritical view, but we all know how well theory works in real life sometimes...
We don't try to create new bugs they are the side affect of fixing other bugs, or adding new features that other people need. And again, if those bugs aren't reported, we have no idea they are present.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Greg KH
Quoted 3 lines
Now what? Do I as a user upgrade my production environment to the latest and greatest kernel experiment, hope that the problems can be fixed quickly, and hope that I don't lose too much data in the process?
No, if you rely on a production environment for your stuff, stick with a disto kernel which has been tested and is backed up by a company that will maintain it over time.
If the purpose of not having a 2.7 branch or longer RCs is to have people test the latest vanilla, you can't simultaneously send users away.
I maintain a number of servers and don't like to depend on a distro for the kernel. I do my tests before deployment and can live with some problems in a specific release (noone is perfect), but I'd like to have a plan B without creating my own branch.
Having security patches in a 2.6.(x-1).y would allow me to test the latest vanilla AND have stable production servers without the rush that usually accompanies a new release followed by a vulnerability.
Signature · 2 lines
Bye, Massimiliano Hofer
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Massimiliano Hofer <[email protected]> wrote:
[...]
Quoted 4 lines
I maintain a number of servers and don't like to depend on a distro for the kernel. I do my tests before deployment and can live with some problems in a specific release (noone is perfect), but I'd like to have a plan B without creating my own branch.
Reasonable.
Quoted 3 lines
Having security patches in a 2.6.(x-1).y would allow me to test the latest vanilla AND have stable production servers without the rush that usually accompanies a new release followed by a vulnerability.
You can certainly keep 2.6.x.y for a while when 2.6.(x+1) shows up, and even wait for 2.6.(x+1).1. Note that the stable series maintainers are sypmathetic to the idea of doing a last 2.6.x.(y+1), flushing the queued patches when 2.6.(x+1) shows up. Is this enough for you?
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines · Horst von Brand
You can certainly keep 2.6.x.y for a while when 2.6.(x+1) shows up, and even wait for 2.6.(x+1).1. Note that the stable series maintainers are sypmathetic to the idea of doing a last 2.6.x.(y+1), flushing the queued patches when 2.6.(x+1) shows up. Is this enough for you?
If a 2.6.x.1 is released and a vulnerability is discovered with the wrong timing, this leaves us with a kernel that has had little or no testing.
We already had a 2.6.x that didn't even boot on half my servers. When 2.6.x.1 is the first bootable version and a security patch arrives, this leaves me with an uncomfortable choice between an old, stable and vulnerable version and a new, shiny and untested one.
Having 2.6.x-1.y and 2.6.x.y would avoid this situation.
Signature · 2 lines
Bye, Massimiliano Hofer
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 36 lines · Greg KH
Quoted 9 lines · Jakob Oestergaard
Quoted 7 lines · Greg KH
Quoted 4 lines · Jakob Oestergaard
In the real world, however, admins currently need to pick out specific versions of the kernel for specific workloads (try running a large fileserver on anything but 2.6.11.11 for example - any earlier or later kernel will barf reliably.
Quoted 6 lines
Quoted 2 lines
Have you filed a but at bugzilla.kernel.org about this? If not, how do you expect it to get fixed?
I don't expect to get it fixed. It's futile. It can get fixed in one version and broken two days later, and it seems the attitude is that that is just fine.
Huh? That is just not true at all. Please give us a bit more credit than that.
Quoted 11 lines
After a long long back-and-forth, 2.6.11 was fixed to the point where it could reliably serve files (at least on uniprocessor configurations - and in my setup I don't see problems on NUMA either, but as far as I know that's just me being lucky).
Right after that, someone thought it was a great idea to pry out the PCI subsystem and shovel in something else. Find, that's great for a development kernel, but for a kernel that's supposed to be stable it's just not something you can realistically do and expect things to work afterwards. And things broke - try mounting 10-20 XFS filesystems simultaneously on 2.6.14. Boom - PCI errors.
Quoted 5 lines
What PCI errors are you speaking of? We did that PCI work to fix a lot of other machines that were having problems. And yes, this did break some working machines, and we are very sorry about this. But in the future, changes to this area will not cause this to happen due to the changes made.
I don't think it's reasonable to get overly upset about *accidental* breakages. People make mistakes, otherwise you don't get progress.
Note that I haven't changed my mind about deliberately removing features for which there is no practical alternative.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KH* Greg KH:
Quoted 9 lines · Jesper Juhl
Quoted 2 lines
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
If people/customers want stability, they already have this option.
It seems that vendor kernels lack most DoS-related fixes. I'm only aware of a single vendor which tracks them to the point that CVE names are assigned.
Vendor kernels are not a panacea, either. With some of the basic support contracts (in the four-figure range per year and CPU), the vendor won't look extensively at random kernel crashes which could (in theory) be attributed to faulty hardware, *and* you don't get community support for these heavily patched kernel collages.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Florian Weimer
* Greg KH:
Quoted 8 lines · Jesper Juhl
Quoted 2 lines
Why can't this be done by distributors/vendors?
It already is done by these people, look at the "enterprise" Linux distributions and their 5 years of maintance (or whatever the number is.)
Quoted 5 lines
Quoted 1 line
If people/customers want stability, they already have this option.
It seems that vendor kernels lack most DoS-related fixes. I'm only aware of a single vendor which tracks them to the point that CVE names are assigned.
If those DoS-related problems are only related to local user DoS's, yes, that is understandable. If you have questions about this, ask the vendor, they usually have a good reason for not including those fixes.
Quoted 5 lines
Vendor kernels are not a panacea, either. With some of the basic support contracts (in the four-figure range per year and CPU), the vendor won't look extensively at random kernel crashes which could (in theory) be attributed to faulty hardware, *and* you don't get community support for these heavily patched kernel collages.
Yes, the lack of community support is one thing you do give up with them.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 9 lines
ase for a stable series.
After 2.6.16, there will be a 2.6.16.y series with the usual stable rules.
After the release of 2.6.17, this 2.6.16.y series will be continued with more relaxed rules similar to the rules in kernel 2.4 since the release of kernel 2.6.0 (e.g. driver updates will be allowed).
this is a contradiction. You can't eat a cake and have it; either you're really low churn (like existing -stable) or you start adding new features like hardware support. the problem with hardware support is that it's not just a tiny driver update. If involves midlayer updates as well usually, and especially if those midlayers diverge between your stable and mainline, the "backports" are getting increasingly unsafe and hard.
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Arjan van de Ven
Quoted 9 lines
ase for a stable series.
After 2.6.16, there will be a 2.6.16.y series with the usual stable rules.
After the release of 2.6.17, this 2.6.16.y series will be continued with more relaxed rules similar to the rules in kernel 2.4 since the release of kernel 2.6.0 (e.g. driver updates will be allowed).
Quoted 7 lines
this is a contradiction. You can't eat a cake and have it; either you're really low churn (like existing -stable) or you start adding new features like hardware support. the problem with hardware support is that it's not just a tiny driver update. If involves midlayer updates as well usually, and especially if those midlayers diverge between your stable and mainline, the "backports" are getting increasingly unsafe and hard.
In the beginning, backporting hardware support is relatively easy, and therefore cherry-picking from mainline 2.6 should be relatively safe.
Things will change as time passes by, but then there's the possibility to open the next branch and bring the older branch into a security-fixes only mode.
Quoted 6 lines
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
For how many years do you think we will be able to ensure that this will stay true?
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines
Quoted 8 lines
this is a contradiction. You can't eat a cake and have it; either you're really low churn (like existing -stable) or you start adding new features like hardware support. the problem with hardware support is that it's not just a tiny driver update. If involves midlayer updates as well usually, and especially if those midlayers diverge between your stable and mainline, the "backports" are getting increasingly unsafe and hard.
In the beginning, backporting hardware support is relatively easy, and therefore cherry-picking from mainline 2.6 should be relatively safe.
and then there's reality. At least in my experience as distro kernel maintainer... you can do this for a few months, but it gets exponentially more expensive after 4 to 5 months. And "safe" is just not true. API, midlayer and locking changes in the newer kernels just void that concept entirely. And then there's the testing dillema; the people who'd run such a branch are EXACTLY the ones who wouldn't test prereleases of such branch (and yes 2.4 suffers from this as well).
I doubt many distros would go for it as well for longer than a few months, simply because the hardware support and other features are going to be needed for them.
Quoted 3 lines
Things will change as time passes by, but then there's the possibility to open the next branch and bring the older branch into a security-fixes only mode.
if you end up with 5 such branches it's no longer fun, trust me on that. Especially if the security fix is in a tricky area or a high flux area, then it's just not a matter of a simple backport anymore, even knowing if you're vulnerable or not is going to be a pain. And then there are the holes that happened to have gone away by later changes... what are you going to do then... put those changes in? that won't work longer term.
Quoted 10 lines
Quoted 7 lines
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
I'd say yes. It doesn't need to support all new functionality, but at least what it does today it should be able to do then. If that really isn't possible maybe udev should be part of the kernel build and per kernel version.
Quoted 3 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
I would argue that this in theory already is the current policy. Now "any" is pretty wide, but still. Maybe any such changes need to be scheduled to specific kernel releases only. Eg only do it every 4th or 5th kernel release.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Arjan van de Ven
Quoted 2 lines
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
I'd say yes. It doesn't need to support all new functionality, but at least what it does today it should be able to do then. If that really isn't possible maybe udev should be part of the kernel build and per kernel version.
I agree with this idea.
--
vda
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Arjan van de VenQuoted 50 lines · Arjan van de Ven
Quoted 10 lines
Quoted 9 lines
this is a contradiction. You can't eat a cake and have it; either you're really low churn (like existing -stable) or you start adding new features like hardware support. the problem with hardware support is that it's not just a tiny driver update. If involves midlayer updates as well usually, and especially if those midlayers diverge between your stable and mainline, the "backports" are getting increasingly unsafe and hard.
Quoted 3 lines
In the beginning, backporting hardware support is relatively easy, and therefore cherry-picking from mainline 2.6 should be relatively safe.
and then there's reality. At least in my experience as distro kernel maintainer... you can do this for a few months, but it gets exponentially more expensive after 4 to 5 months. And "safe" is just not true. API, midlayer and locking changes in the newer kernels just void that concept entirely. And then there's the testing dillema; the people who'd run such a branch are EXACTLY the ones who wouldn't test prereleases of such branch (and yes 2.4 suffers from this as well).
I doubt many distros would go for it as well for longer than a few months, simply because the hardware support and other features are going to be needed for them.
Quoted 3 lines
Things will change as time passes by, but then there's the possibility to open the next branch and bring the older branch into a security-fixes only mode.
if you end up with 5 such branches it's no longer fun, trust me on that. Especially if the security fix is in a tricky area or a high flux area, then it's just not a matter of a simple backport anymore, even knowing if you're vulnerable or not is going to be a pain. And then there are the holes that happened to have gone away by later changes... what are you going to do then... put those changes in? that won't work longer term.
Quoted 9 lines
Quoted 8 lines
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
Quoted 8 lines
Quoted 2 lines
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
I'd say yes. It doesn't need to support all new functionality, but at least what it does today it should be able to do then. If that really isn't possible maybe udev should be part of the kernel build and per kernel version.
Most problems are avoided when packages closely linked to the kernel like udev and pcmcia will be updated by the distro together with the kernel by way of package version dependencies matching for example 2.6.14 to udev 065-069 and kernel 2.6.15 to udev 070. udev 070 and later could block kernels <=2.6.14.
udev bit me recently when a scanner stopped working after updating to udev 070. In that way I had a chance to figure out how udev works and how to make some rules. Neat! ;)
Perhaps extra care should be taken by the distro to not break the 50-udev.rules configuration file.
Quoted 10 lines
Quoted 4 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
I would argue that this in theory already is the current policy. Now "any" is pretty wide, but still. Maybe any such changes need to be scheduled to specific kernel releases only. Eg only do it every 4th or 5th kernel release.
My 2 cents:
Test drive some rc's (2.6.15-rc)
Use current -stable kernel as much as possible (2.6.14.3) Critical apps use -stable -1 or -2 (2.6.13.x or 2.6.12.x)
Using -stable to -stable -2 one is about 3 months behind the latest and greatest instability ;).
As to security, most vulnerabilities are hard to exploit remotely and practical security can be much more improved by hiding detailed software versions from clients. Apache 2 on linux 2.6 will do instead of providing full vendor specific package versions!
As to drivers, in case 3 month driver delay matters, HW vendor can improve situation substantially by not waiting 6+ months before (if at all) releasing drivers/docs for linux!
Michael
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Michael Frank <[email protected]> wrote:
[...]
Quoted 2 lines
As to security, most vulnerabilities are hard to exploit remotely
Right.
Quoted 2 lines
and practical security can be much more improved
by hiding detailed software versions from clients.
Ever heard of nmap <http://www.nmap.org>? Or perhaps noticed all kinds of attacks against Linux using old exploits or Windows specific ones? Hiding versions is /not/ secure. At most marginally so, and the pain for whoever needs the version for legitimate reasons just isn't worth it.
Quoted 8 lines
Apache
2 on linux 2.6 will do instead of providing full vendor specific package versions!As to drivers, in case 3 month driver delay matters, HW vendor can improve situation substantially by not waiting 6+ months before (if at all) releasing
drivers/docsfor linux!
For /server/ type workloads, where you /need/ stability, you carefully pick the hardware and then run a selected "enterprise" distro on it. The distro people do the hard work of keeping your kernel up to date and secure. And even worry about a smooth upgrade to the next version. For a price, sure. But either you really need it (and gladly pay the price) or you don't (in which case you have nothing to complain about).
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Horst von Brand
Michael Frank <[email protected]> wrote:
[...]
Quoted 2 lines
As to security, most vulnerabilities are hard to exploit remotely
Quoted 7 lines
Right.
Quoted 3 lines
and practical security can be much more
improved by hiding detailed software versions from clients.Ever heard of nmap <http://www.nmap.org>?
I wrote my original post with nmap in mind.
I use nmap all the time, it is a excellent tool. At times I used nmap to scan those IP's who scan my IP and have unleashed at times a barrage of counter-scans to the point of bringing my connection pretty much down. Some of those scanners must have big pipes.
Quoted 3 lines
Or perhaps
noticed all kinds of attacks against Linux using old exploits or Windows specific ones?
100s to 1000s of unsolicited packets mainly to windows specific service ports day and also several burst attacks a day. These days I just leave the firewall logging off in order to play less with nmap ;)
Quoted 2 lines
Hiding versions is
/not/ secure. At most marginally so,
Sorry, do not concur. Unlike windows and such, linux is a _fast_ moving target. The best bet to crack it a _inside_ job by a trusted perpetrator (for example the debian case or the corruption of the kernels bk derived cvs repo ), which still ring bells... Remote exploitation of the odd random vulnerability in the absence of detailed version info is as likely as winning a jackpot.
Quoted 3 lines
and the pain for
whoever needs the version for legitimate reasons just isn't worth it.
Oh well, If I have a legitimate requirement for the detailed versions someone is running, I can ask.
Again, most violations are made possible by:
a) access to hardware or admin/root passwords (what was the kernel.org case tracked to?)
b) access to version info and utilizing a exploit short term (the debian case)
IMHO, to have good security, 1) use open source and 2) sound implementation of common sense security procedures beginning with the basic doctrine who does not have to know won't know. Yes, some things seem never to change :-(
Quoted 9 lines
Quoted 8 lines
Apache 2 on linux 2.6 will do instead of providing full vendor specific package versions!
As to drivers, in case 3 month driver delay matters, HW vendor can improve situation substantially by not waiting 6+ months before (if at all) releasing
drivers/docsfor linux!
Quoted 7 lines
For /server/ type workloads, where you /need/ stability, you carefully pick the hardware and then run a selected "enterprise" distro on it. The distro people do the hard work of keeping your kernel up to date and secure. And even worry about a smooth upgrade to the next version. For a price, sure. But either you really need it (and gladly pay the price)
sure
Quoted 2 lines
or you don't (in which case you
have nothing to complain about).
kernel.org kernels and gentoo linux will do for me.
Thank you
Michael
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 11 lines · Adrian Bunk
Things will change as time passes by, but then there's the possibility to open the next branch and bring the older branch into a security-fixes only mode.
Quoted 6 lines
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
Quoted 2 lines
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
I found myself chasing some genuine bugs in that code to please GCC 4 (which doesn't tolerate extern blah declarations before static blah definitions), and some idiotic breakage when inter_module_get was dropped somewhen between 2.6.8 (where the modules compiled just fine) and 2.6.13 (where they didn't as functions had been removed). And there's no point arguing about deprecation warnings being around, interfaces can be removed between 2.6 and 2.8 but not between 2.6.foo.bar and 2.6.foo.baz. Why not use
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,8,0)
or similar to automatically disable such interfaces at the given version?
Quoted 3 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
Right. This effectively means to call the beast 2.8.0 if you feel you must break the applications.
Quoted 2 lines
For how many years do you think we will be able to ensure that this will stay true?
Well, the current model, since it has been in effect, is just "let's break the interfaces at will, but let's not hint anyone, so let's always just bump the patchlevel no matter how intrusive the change is", and the bandaid 2.6.M.N releases cannot cover the fact that the M -> M+1 transition causes breakage.
Effectively, 2.6.X behaves like a bleeding edge development ("everything changes") kernel such as 2.3 or 2.5; it isn't stable because some code monkeys claim it is. You cannot declare the can of pea soup in front of you "open" either.
Linux is in fact light years away from being "stable", and while it was relatively easy to move forward between 2.4.X releases and even 2.4.X and some early 2.6.X release, moving between 2.6.X and 2.6.Y means switching user-space, too, and chances are the new user-space doesn't work with the old kernel.
--
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Matthias Andree
Quoted 3 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
Right. This effectively means to call the beast 2.8.0 if you feel you must break the applications.
Looks like things are leaving clear the need of 2.7 for those developments. This is my point of view.
Signature · 8 lines
O T A V I O S A L V A D O R --------------------------------------------- E-mail: [email protected] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio --------------------------------------------- "Microsoft gives you Windows ... Linux gives you the whole house."
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 7 lines · Matthias Andree
Quoted 7 lines
Quoted 7 lines
the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that)
Well as a mildly technical 'user' who's been tracking the 2.6 series I can't recall having to update _any_ userland packages due to kernel changes. An example of this would be helpful.
Quoted 5 lines
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
As many here say. Too bad, we really don't care. Hardware providers should have the requisite relationships with the distros and target their management utilities to those. Surely no business using this sort of high end hardware is running anything other than RHEL or SLES etc ?
Quoted 9 lines
I found myself chasing some genuine bugs in that code to please GCC 4 (which doesn't tolerate extern blah declarations before static blah definitions), and some idiotic breakage when
inter_module_getwas dropped somewhen between 2.6.8 (where the modules compiled just fine) and 2.6.13 (where they didn't as functions had been removed). And there's no point arguing about deprecation warnings being around, interfaces can be removed between 2.6 and 2.8 but not between
See above.
Quoted 4 lines
Well, the current model, since it has been in effect, is just "let's break the interfaces at will, but let's not hint anyone, so let's always
Only kernel interfaces. And that's too bad for out of kernel modules.
Quoted 3 lines
Linux is in fact light years away from being "stable", and while it was
If you want stable you want a distro 'enterprise' version.
Quoted 5 lines
and some early 2.6.X release, moving between 2.6.X and 2.6.Y means switching user-space, too, and chances are the new user-space doesn't work with the old kernel.
In my experience this isn't the case.
Cheers
David
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · David Ranson
Quoted 7 lines · Matthias Andree
Quoted 7 lines
Quoted 7 lines
the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that)
Quoted 3 lines
Well as a mildly technical 'user' who's been tracking the 2.6 series I can't recall having to update _any_ userland packages due to kernel changes. An example of this would be helpful.
udev ;)
http://seclists.org/lists/linux-kernel/2005/Dec/0180.html
-- Steve
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Steven Rostedt
udev ;)
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
David
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · David Ranson
Quoted 5 lines · Steven Rostedt
udev ;)
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
- support for ipfwadm and ipchains was removed during 2.6
- devfs support was removed during 2.6
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pending
Quoted 1 line
David
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seednewbie - mdadm create raid1 mirrors on large drives
I hope this is the correct list for this question.
I've just recently begun using mdadm to set up some arrays using large drives (300-400Gb). One of the things I don't understand is this: when you first create a raid1 (mirrored) array from two drives mdadm insists on mirroring the contents of the first drive to the second even though the drives are entirely blank (e.g. new drives don't have anything on them). In one configuration I have, this takes about 16 hours on a 400Gb drive. When I do 5 of them simultaneously this takes 2+ days to complete. Is there some way to tell mdadm that you want to create a mirrored set but skip this rather long initial mirroring process? I don't really see that it actually accomplishes anything.
Thanks in advance for your assistance.
-Larry Bates
Re: newbie - mdadm create raid1 mirrors on large drives
Quoted 1 line · Larry Bates
I hope this is the correct list for this question.
No list is right for hijacking threads. Don't do that again.
Please use "New Mail" or however it's named for a new different topic. Your message has nothing to do with stable kernel fork discussion.
Signature · 1 line
Matthias Andree
Re: newbie - mdadm create raid1 mirrors on large drives
In reply to Larry BatesQuoted 1 line · On Saturday December 3, [email protected] wrote:
I hope this is the correct list for this question.
[email protected] is possibly better, but linux-kernel is probably a suitable catch-all.
Quoted 9 lines
I've just recently begun using mdadm to set up some arrays using large drives (300-400Gb). One of the things I don't understand is this: when you first create a raid1 (mirrored) array from two drives mdadm insists on mirroring the contents of the first drive to the second even though the drives are entirely blank (e.g. new drives don't have anything on them).
Well... they do have something one them - lots of zeros and ones, or maybe just zeros, or maybe just ones. Sure, you may not be interested in that data, but it is there.
Quoted 7 lines
In one configuration I have, this takes
about 16 hours on a 400Gb drive. When I do 5 of them simultaneously this takes 2+ days to complete. Is there some way to tell mdadm that you want to create a mirrored set but skip this rather long initial mirroring process? I don't really see that it actually accomplishes anything.
No, there is no way to tell mdadm to skip the initial copying process. It is not clear to me that you really want to do this(*) (though on the "enough rope" principle I'm probably going to extend the "--assume-clean" option to work in --create mode).
I suggest you simply ignore the fact that it is doing the copy. Just keep using the array as though it wasn't. If this seems to be impacting over-all system performance, tune /proc/sys/dev/raid/speed_* to slow it down even more.
If you reboot, it should remember where it was up to and restart from the same place (providing you are using a 2.6 kernel).
If you have 5 of these 400Gb raid1's, then I suspect you really want to avoid the slow resync that happens after a crash. You should look into adding a bitmap write-intent log. This requires 2.6.14, and mdadm 2.1, and is as easy as
mdadm --grow --bitmap=internal /dev/md3
while the array is running.
This should dramatically reduce resync time, at a possible small cost in write throughput. Some limited measurements I have done suggest up-to 10% slowdown, though usually less. Possibly some tuning can make it much better.
(*)
A raid array can suffer from sleeping bad blocks. i.e. blocks that you cannot read, but normally you never do (because they haven't been allocated to a file yet). When a drive fails, and you are recovering the data onto a spare, hitting that sleeper can kill your array.
For this reason it is good to regularly (daily, or weekly, maybe monthly) read through the entire array making sure everything is OK. In 2.6.16 (with complete functionality in 2.6.17) you will be able to trigger a background read-test of the whole array:
echo check > /sys/block/mdX/md/sync_action
If you were to create an array with --assume-clean, then whenever you run this it will report lots of errors, though you can fix them with
echo repair > /sys/block/mdX/md/sync_action
If you are going to be doing that (and I would recommend it) then you may as well allow the initial sync, especially as you can quite happily ignore the fact that it is happening.
NeilBrown
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 3 lines · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Quoted 3 lines
- devfs support was removed during 2.6
Did this affect many 'real' users?
Quoted 5 lines
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pending
I don't use any of these. I guess pcmcia-cs may be disruptive for laptop users.
So far I don't see evidence to suggest huge repeated userspace breakages between Kernel versions that were implied earlier in this thread. Whatever, we aren't going to see any more stable branches without volunteers to do the spadework. As has been pointed out, this won't always be an easy task.
David
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · David Ranson
Quoted 3 lines · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these. That opportunity was missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.
Quoted 3 lines
Quoted 1 line
- devfs support was removed during 2.6
Did this affect many 'real' users?
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
Quoted 6 lines
Quoted 3 lines
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pendingI don't use any of these. I guess pcmcia-cs may be disruptive for laptop users.
Who cares what you or I use? It's a commonly acknowledged policy that "stable" releases do not remove features that are good enough for some. Linux 2.6 is not "stable" in this regard.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 2 lines · Matthias Andree
A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning.
So in your opinion we can't add support for new hardware to a stable kernel either because there's a chance of breaking something that worked before, which brings us right back to "stable" meaning "no progress allowed", which begs the question of why you want to upgrade at all.
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 8 lines · Lee Revell
Quoted 2 lines · Matthias Andree
A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning.
So in your opinion we can't add support for new hardware to a stable kernel either because there's a chance of breaking something that worked before, which brings us right back to "stable" meaning "no progress allowed", which begs the question of why you want to upgrade at all.
Perhaps I did not word not clearly enough, please bear with me as I'm not a native speaker.
There's a gray area between these two extremes. I don't mind if new drivers are added, not even if they touch other parts of the code if these changes are thoroughly (and I mean thoroughly, not a smoke test of the "works for me" kind) examined.
If devfs had been marked "DEPRECATED, WILL BE REMOVED FROM 2.6.0", all would have been fine. (I don't recall the exact version, 2.6.12? It wasn't known beforehand), I certainly do not expect new drivers that are added to support it.
First step, make a note "this driver has been added in Linux 2.6.14" so that everyone is aware the driver doesn't need to support devfs as that one was already deprecated then the driver moved in. Even better, mark which deprecated subsystems are unsupported by the driver.
Second, schedule for removal such subsystems well ahead of time, for instance, "DEPRECATED, WILL BE REMOVED JUST BEFORE 2.8.0", and only use minor releases to that extent.
The point is, removing something that has worked well enough that some people had a reason to use it, is not "stable".
Third, IF udev is so sexy but OTOH a real kernel-space devfs can be done in 200 LoC as has been claimed so often, why in hell is this not happening? Switch "broken bloaty bulky devfs" to "lean & clean devfs"? This ship would have been flying the "clean-up nation" flags.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 2 lines · Matthias Andree
The point is, removing something that has worked well enough that some people had a reason to use it, is not "stable".
Please remember, no one is calling 2.6 "stable" anymore than they are calling it "development". The current development model is different than what we used to do pre 2.6. See the archives for details about this if you want more information.
Quoted 2 lines
Third, IF udev is so sexy but OTOH a real kernel-space devfs can be done in 200 LoC as has been claimed so often,
282 LoC:
drivers/base/class.c | 7 + fs/Kconfig | 3 fs/Makefile | 1 fs/ndevfs/Makefile | 4 fs/ndevfs/inode.c | 249 +++++++++++++++++++++++++++++++++++++++++++++++++ fs/partitions/check.c | 6 + include/linux/ndevfs.h | 13 ++ 7 files changed, 282 insertions(+), 1 deletion(-)
Quoted 1 line
why in hell is this not happening?
Because it's not the correct solution.
Quoted 2 lines
Switch "broken bloaty bulky devfs" to "lean & clean devfs"? This ship would have been flying the "clean-up nation" flags.
Again, because an in-kernel devfs is not the correct thing to do. devfs has been disabled for a few months now, and I don't think anyone has missed it yet :)
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Greg KH
Quoted 2 lines
Switch "broken bloaty bulky devfs" to "lean & clean devfs"? This ship would have been flying the "clean-up nation" flags.
Again, because an in-kernel devfs is not the correct thing to do. devfs has been disabled for a few months now, and I don't think anyone has missed it yet :)
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available; devfs has the effect of trying to load a module when a program looks for the devices it provides-- while it can cause problems, it does have a possibility to work better. Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsi
2. my sound card is autodetected and the drivers loaded, but the OSS emulation modules are omitted; with devfs, they would be autoloaded when an app tried to use OSS
devfs also has the advantage of keeping the module info all in one place-- the kernel or the module. In particular, with udev the detection and /dev info is scattered into different locations of the filesystem. This can probably be fixed easily simply by having udev read such info from modules or via a /sys entry, though.
Signature · 3 lines
Luke-Jr Developer, Utopios http://utopios.org/
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 20 lines · Luke-Jr
Quoted 7 lines · Greg KH
Quoted 3 lines
Switch "broken bloaty bulky devfs" to "lean & clean devfs"? This ship would have been flying the "clean-up nation" flags.
Again, because an in-kernel devfs is not the correct thing to do. devfs has been disabled for a few months now, and I don't think anyone has missed it yet :)
Well, devfs does have some abilities udev doesn't:
hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available; devfs has the effect of trying to load a module when a program looks for the devices it provides-- while it can cause problems, it does have a possibility to work better. Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsi
2. my sound card is autodetected and the drivers loaded,
Quoted 8 lines
but the OSS emulation modules are omitted; with devfs, they would be autoloaded when an app tried to use OSS devfs also has the advantage of keeping the module info all in one place-- the kernel or the module. In particular, with udev the detection and /dev info is scattered into different locations of the filesystem. This can probably be fixed easily simply by having udev read such info from modules or via a /sys entry, though.
Seems your complaints are related to missing/broken configuration (of your distribution).
Here are some references which may be of help:
http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html
http://www.gentoo.org/doc/en/udev-guide.xml
http://gentoo-wiki.com/HOWTO_Customizing_UDEV
http://ubuntuforums.org/archive/index.php/t-11718.html
IME, udev is easier to manage than devfs because there are tools such as udevtest.
Please see also manuals for udevstart udevtest, udevinfo, udevcontrol
Also strace udevstart is interesting...
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Luke-JrQuoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today? And udev wasn't created to do everything that devfs does. And devfs can't do everything that udev can (by far...)
Quoted 3 lines
devfs has the effect of trying to load a module when a program looks for the devices it provides-- while it can cause problems, it does have a possibility to work better.
Sorry, but that model of loading modules is very broken and it is good that we don't do that anymore (as you allude to.)
Quoted 3 lines
Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsi
Sounds like a broken distro configuration :)
Quoted 3 lines
2. my sound card is autodetected and the drivers loaded, but the OSS emulation modules are omitted; with devfs, they would be autoloaded when an app tried to use OSS
Again, broken distro configuration :)
Quoted 2 lines
devfs also has the advantage of keeping the module info all in one place-- the kernel or the module.
What?
Quoted 4 lines
In particular, with udev the detection and /dev info is scattered into different locations of the filesystem. This can probably be fixed easily simply by having udev read such info from modules or via a /sys entry, though.
What information are you talking about here?
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today?
Nope, but I don't see how udev can possibly detect something that doesn't let the OS know it's there-- except, of course, loading the driver for it and seeing if it works.
Quoted 1 line
And udev wasn't created to do everything that devfs does.
Which might be a case for leaving devfs in. *shrug*
Quoted 1 line
And devfs can't do everything that udev can (by far...)
Didn't say it could...
Quoted 5 lines
Quoted 3 lines
Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsiSounds like a broken distro configuration :)
Well, I was assuming you kept Gentoo's udev packages up to date. ;)
[ebuild R ] sys-fs/udev-070-r1 (-selinux) -static 429 kB
Quoted 8 lines
Quoted 6 lines
devfs also has the advantage of keeping the module info all in one place-- the kernel or the module.
In particular, with udev the detection and /dev info is scattered into different locations of the filesystem. This can probably be fixed easily simply by having udev read such info from modules or via a /sys entry, though.What information are you talking about here?
I'm assuming everything in /etc/udev/rules.d/50-udev.rules used to be in the kernel for devfs-- perhaps it was PAM though, I'm not sure. Other than that, I don't expect that simply installing a new kernel module will allow the device to be detected automatically, but that some hotplug or udev configurations will need to be updated also.
Signature · 3 lines
Luke-Jr Developer, Utopios http://utopios.org/
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Luke-Jr
Quoted 6 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today?
Nope, but I don't see how udev can possibly detect something that doesn't let the OS know it's there-- except, of course, loading the driver for it and seeing if it works.
Stuff shows up in /sys whether or not Linux has a driver loaded for it.
ls -l /sys/bus/*/devices
Hotplug insertion events are for when the _device_ shows up, not for when the driver is loaded.
Quoted 3 lines
Quoted 1 line
And udev wasn't created to do everything that devfs does.
Which might be a case for leaving devfs in. *shrug*
I think it was a polite way of saying "udev doesn't suck, have unfixable races, randomly crash your system..."
Quoted 7 lines
Quoted 1 line
What information are you talking about here?
I'm assuming everything in
/etc/udev/rules.d/50-udev.rulesused to be in the kernel for devfs-- perhaps it was PAM though, I'm not sure. Other than that, I don't expect that simply installing a new kernel module will allow the device to be detected automatically, but that some hotplug or udev configurations will need to be updated also.
On an unrelated note, the proposed file format for busybox's mdev looks something like:
hd[a-z] 0:3 700
hd[a-z][0-9]* 0:3 740
.* 0:0 700
There's a little more to it than that, but really, specifying ownership and permissions is all we _really_ care about. (We're not trying to obsolete udev.)
The point is, 90% of the complexity of udev is optional. This _can_ be a lot simpler if you're not trying to tackle strange persistent naming issues resulting in dynamically generated symlinks, and similar fun. (Which we may add the ability to do as compile-time config options later, but perhaps not until somebody actually misses them...)
We really don't forsee having to update mdev for deal with new kernel versions... ever, if we can help it.
And a dynamic module loader hanging off of /sbin/hotplug is probably (conceptually) a different tool from mdev...
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Rob Landley
Quoted 6 lines · Luke-Jr
Quoted 5 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Are you sure about that today?
Nope, but I don't see how udev can possibly detect something that doesn't let the OS know it's there-- except, of course, loading the driver for it and seeing if it works.
Stuff shows up in /sys whether or not Linux has a driver loaded for it.
Only if Linux is aware it exists. I'm thinking of those old ISA cards and such.
Signature · 3 lines
Luke-Jr Developer, Utopios http://utopios.org/
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 8 lines · Luke-Jr
Quoted 5 lines
Quoted 3 lines
Nope, but I don't see how udev can possibly detect something that doesn't let the OS know it's there-- except, of course, loading the driver for it and seeing if it works.
Stuff shows up in /sys whether or not Linux has a driver loaded for it.
Only if Linux is aware it exists. I'm thinking of those old ISA cards and such.
A) This is only true for obsolete hardware. Can you name an example that's currently being manufactured? (I'm trying to figure out if serial mice count, not that you really need kernel support to detect those.)
B) You can insmod the module from userspace to actively probe for stuff. If the kernel doesn't know either until it probes, and you can trigger the probe at will, what additional kernel support do you need?
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Luke-JrQuoted 8 lines · Luke-Jr
Quoted 6 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today?
Quoted 7 lines
Nope, but I don't see how udev can possibly detect something that doesn't let the OS know it's there-- except, of course, loading the driver for it and seeing if it works.
Quoted 1 line
And udev wasn't created to do everything that devfs does.
Which might be a case for leaving devfs in. *shrug*
Heh, no. Please go look up why devfs was deleted, this one broken feature is not a good enough reason to keep it around.
Quoted 4 lines
Quoted 1 line
And devfs can't do everything that udev can (by far...)
Didn't say it could...
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsiSounds like a broken distro configuration :)
Well, I was assuming you kept Gentoo's udev packages up to date. ;)
[ebuild R ] sys-fs/udev-070-r1 (-selinux) -static 429 kB
That's the latest stable udev release in Gentoo, yes. Do you have problems with that one? If so, please file them in the proper Gentoo bugzilla.
And yes, Gentoo is lagging a bit on the latest udev support (073 is in the tree, but 076 has been released.) That's totally my fault, and you can blame my lack of free time to do what is needed to fully intregrate it (due to some very good snow in our local mountains...)
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
devfs also has the advantage of keeping the module info all in one place-- the kernel or the module.
In particular, with udev the detection and /dev info is scattered into different locations of the filesystem. This can probably be fixed easily simply by having udev read such info from modules or via a /sys entry, though.What information are you talking about here?
I'm assuming everything in
/etc/udev/rules.d/50-udev.rulesused to be in the kernel for devfs-- perhaps it was PAM though, I'm not sure.
That is not true, it was not.
Quoted 3 lines
Other than that, I don't expect that simply installing a new kernel module will allow the device to be detected automatically, but that some hotplug or udev configurations will need to be updated also.
Have you tried this? What "new kernel module" are you speaking of?
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 25 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today? And udev wasn't created to do everything that devfs does. And devfs can't do everything that udev can (by far...)
Quoted 3 lines
devfs has the effect of trying to load a module when a program looks for the devices it provides-- while it can cause problems, it does have a possibility to work better.
Sorry, but that model of loading modules is very broken and it is good that we don't do that anymore (as you allude to.)
Quoted 2 lines
Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsi
Quoted 7 lines
Sounds like a broken distro configuration :)
Quoted 1 line
2. my sound card is autodetected and the drivers loaded, but the OSS emulation modules are omitted; with devfs, they would be autoloaded when an app tried to use OSS
Again, broken distro configuration :)
If a new udev config is needed with every new kernel, why isn't it in the kernel tarball? Is that what you mean by "broken distro configuration?" The info should be in /proc or /sys and not in an external config file, particularly if a different versions per-kernel is needed and people are trying new kernels and perhaps falling back to the old.
Have "make install" drop the udev config in /boot like the initrd file. The the boot could create an slink to "/boot/$(uname -r)-udev" or some such.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Bill Davidsen
If a new udev config is needed with every new kernel, why isn't it in the kernel tarball? Is that what you mean by "broken distro configuration?" The info should be in /proc or /sys and not in an external config file, particularly if a different versions per-kernel is needed and people are trying new kernels and perhaps falling back to the old.
Every distro has different needs for its device naming and groups and other intergration into the boot process. To force all of them to unify on one-grand-way-of-doing-things would just not work out at all.
Look at all of the variations in the udev tarball between the different vendor configurations (we put them in there for other people to base their distro off of, if they want to.)
So providing this config in the kernel will just not work, sorry.
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Greg KH
Quoted 6 lines · Bill Davidsen
If a new udev config is needed with every new kernel, why isn't it in the kernel tarball? Is that what you mean by "broken distro configuration?" The info should be in /proc or /sys and not in an external config file, particularly if a different versions per-kernel is needed and people are trying new kernels and perhaps falling back to the old.
Quoted 3 lines
Every distro has different needs for its device naming and groups and other intergration into the boot process. To force all of them to unify on one-grand-way-of-doing-things would just not work out at all.
Did I say that. No, I said it would be desirable to provide a working config with the kernel, to which something could be symlinked. This no more "forces" distributions to do anything than LSB. It would provide a default, it would provide something working, and if I didn't like it I could change it. But I wouldn't have to try and change thing way up in initrd so I can boot one kernel or another...
Quoted 6 lines
Look at all of the variations in the udev tarball between the different vendor configurations (we put them in there for other people to base their distro off of, if they want to.)
So providing this config in the kernel will just not work, sorry.
We have standard libraries, header files, system calls, why is a standard in this case a bad thing? Actually not even a standard, perhaps, a default. It wouldn't make it one bit harder to have custom names, for those who believe different is better.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 14 lines · Bill Davidsen
Quoted 9 lines · Greg KH
Quoted 6 lines · Bill Davidsen
If a new udev config is needed with every new kernel, why isn't it in the kernel tarball? Is that what you mean by "broken distro configuration?" The info should be in /proc or /sys and not in an external config file, particularly if a different versions per-kernel is needed and people are trying new kernels and perhaps falling back to the old.
Quoted 3 lines
Every distro has different needs for its device naming and groups and other intergration into the boot process. To force all of them to unify on one-grand-way-of-doing-things would just not work out at all.
Quoted 6 lines
Did I say that. No, I said it would be desirable to provide a working config with the kernel, to which something could be symlinked. This no more "forces" distributions to do anything than LSB. It would provide a default, it would provide something working, and if I didn't like it I could change it. But I wouldn't have to try and change thing way up in initrd so I can boot one kernel or another...
That already works today. All distros I know are capable to run kernel.org kernels, if you care yourself, that the rootfs is accessible.
Quoted 10 lines
Quoted 5 lines
Look at all of the variations in the udev tarball between the different vendor configurations (we put them in there for other people to base their distro off of, if they want to.)
So providing this config in the kernel will just not work, sorry.
We have standard libraries, header files, system calls, why is a standard in this case a bad thing? Actually not even a standard, perhaps, a default. It wouldn't make it one bit harder to have custom names, for those who believe different is better.
Just give it its time. It will happen without anybody claiming to have or to be a standard. We are already much more similar than we've ever been across the current devel releases of all major distros. The complete replacement of hotplug by udev rules, kernel uevents and kernel event replay triggers made the situation so much simpler and better than it ever was.
It's, as in most cases, not about someone defining some standard, talk a lot about it, create an interest group, write a noisy paper... - it's the whole lot of real work to come up with a solution that is convincing enough for the involved parties, and to manage all the different interests people have and still get things done at the same time. It has almost nothing to do with a "standard".
Convergence will just happen, cause it makes sense and there is a reasonable way to do it. And there was no such thing in that area in the past that made this kind of sense.
And yeah, the never ending discussion about stupid options like devfs does not help anything here. It should have been removed a long time ago, so that the the confused people start to walk in the right direction instead of delaying the needed convergence progress again and again.
Thanks,
Kay
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 23 lines · Bill Davidsen
Quoted 22 lines · Greg KH
Quoted 3 lines · Luke-Jr
Well, devfs does have some abilities udev doesn't: hotplug/udev doesn't detect everything, and can result in rarer or non-PnP devices not being automatically available;
Are you sure about that today? And udev wasn't created to do everything that devfs does. And devfs can't do everything that udev can (by far...)
Quoted 3 lines
devfs has the effect of trying to load a module when a program looks for the devices it provides-- while it can cause problems, it does have a possibility to work better.
Sorry, but that model of loading modules is very broken and it is good that we don't do that anymore (as you allude to.)
Quoted 3 lines
Interesting effects of switching my desktop from devfs to udev:
1. my DVD burners are left uninitialized until I manually modprobe ide-cd or (more recently) ide-scsiSounds like a broken distro configuration :)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
2. my sound card is autodetected and the drivers loaded, but the OSS emulation modules are omitted; with devfs, they would be autoloaded when an app tried to use OSS
Again, broken distro configuration :)
If a new udev config is needed with every new kernel, why isn't it in the kernel tarball?
Why isn't inittab in the kernel tarball?
I have a shell script that initializes /dev. (I've posted it here a few times, somebody ported it to C, and a micro-udev replacement will go into busybox in 1.2.)
Why isn't there a command shell in the kernel tarball? Kinda hard to use your system without a shell...
As far as I can tell, what broke with udev was their embedded version of "libsysfs", which is an abstraction layer I've _never_ understood the point of. (Because opening single value files in /sys is just too hard. Nobody needed a "libproc", the parsing of which is actual work, but they felt a need a libsysfs. Uh-huh...)
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Rob Landley
As far as I can tell, what broke with udev was their embedded version of "libsysfs", which is an abstraction layer I've _never_ understood the point of. (Because opening single value files in /sys is just too hard. Nobody needed a "libproc", the parsing of which is actual work, but they felt a need a libsysfs. Uh-huh...)
The original goal of libsysfs was to have a library that handled all of the direct sysfs calls, and have it create structures that looked something like what sysfs exported (devices, busses, etc.)
Then, if things changed in the sysfs layout or structure, only libsysfs would need to be changed, and all apps that used it would continue to work just fine.
But in reality, it was only used by udev, and was very fragile. So fragile udev is thinking of ripping it out as it has had a lot of problems in the past.
Hope this explains things better.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 13 lines · Greg KH
Quoted 2 lines · Matthias Andree
The point is, removing something that has worked well enough that some people had a reason to use it, is not "stable".
Please remember, no one is calling 2.6 "stable" anymore than they are calling it "development". The current development model is different than what we used to do pre 2.6. See the archives for details about this if you want more information.
Quoted 2 lines
Third, IF udev is so sexy but OTOH a real kernel-space devfs can be done in 200 LoC as has been claimed so often,
282 LoC:
...
Quoted 3 lines
Quoted 1 line
why in hell is this not happening?
Because it's not the correct solution.
More detail on this:
On the busybox list we're currently working out a design for mdev, the micro-udev that'll go into busybox 1.2. So we're thinking about this issue pretty carefully, as we speak. What's the minimal amount of work we can't get away with not doing?
And much as we'd like to, we can't eliminate the config file. In mdev we can accept the kernel's suggested names for devices, throw everything into a single directory with no subdirectories, even configure out hotplugging support (since not all embedded devices need that). But nowhere in sys is there any hint about the correct ownership and permissions for a device, and you can't create a device node without specifying that.
The fundamental problem is that the kernel _can't_ tell us this through /sys because the kernel has no idea what users and groups are on a given system. It can't, and it shouldn't. That's not it's job. (It deals with uid and gid and never looks at /etc/passwd or /etc/groups. And if it doesn't know who should own what, it can't know what permissions they should have either.)
So no in-kernel filesystem can get this right without help from userspace (even devfs had devfsd), and as soon as you've got a userspace daemon to tell the kernel who is who you might as well do the whole thing there, now that the kernel is exporting everyting _else_ we need to know via /sys and /sbin/hotplug.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Rob Landley
So no in-kernel filesystem can get this right without help from userspace (even devfs had devfsd), and as soon as you've got a userspace daemon to tell the kernel who is who you might as well do the whole thing there, now that the kernel is exporting everyting _else_ we need to know via /sys and
/sbin/hotplug.
/sbin/hotplug is suboptimal. Even a pretty fast machine is slowed down pretty significantly by the ~thousand fork and exec that take place during startup. For the most common devices -- common tty, pty, floppy, etc that every system has, this is a plain waste of resources -- otherwise known as bloat.
-ben
Signature · 2 lines
"You know, I've seen some crystals do some pretty trippy shit, man." Don't Email: <[email protected]>.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Benjamin LaHaise
Quoted 5 lines · Rob Landley
So no in-kernel filesystem can get this right without help from userspace (even devfs had devfsd), and as soon as you've got a userspace daemon to tell the kernel who is who you might as well do the whole thing there, now that the kernel is exporting everyting _else_ we need to know via /sys and
/sbin/hotplug.
/sbin/hotplugis suboptimal. Even a pretty fast machine is slowed down pretty significantly by the ~thousand fork and exec that take place during startup.
Why do you need hotplug events on startup? Can't you just scan /sys for "dev" entries do the initial populate of /dev from that?
Quoted 3 lines
For the most common devices -- common tty, pty, floppy, etc that every system has, this is a plain waste of resources -- otherwise known as bloat.
I get those from a scan of /sys, and only care about hotplug events that come in after that. (Could just be me...)
Quoted 1 line
-ben
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Rob Landley
Quoted 3 lines
/sbin/hotplugis suboptimal. Even a pretty fast machine is slowed down pretty significantly by the ~thousand fork and exec that take place during startup.Why do you need hotplug events on startup? Can't you just scan /sys for "dev" entries do the initial populate of /dev from that?
That's my point: I don't. Yet the kernel tries to exec /sbin/hotplug on startup around 1000 times.
-ben
Signature · 2 lines
"You know, I've seen some crystals do some pretty trippy shit, man." Don't Email: <[email protected]>.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Benjamin LaHaise
Quoted 4 lines · Rob Landley
Quoted 3 lines
/sbin/hotplugis suboptimal. Even a pretty fast machine is slowed down pretty significantly by the ~thousand fork and exec that take place during startup.
Quoted 7 lines
Quoted 2 lines
Why do you need hotplug events on startup? Can't you just scan /sys for "dev" entries do the initial populate of /dev from that?
That's my point: I don't. Yet the kernel tries to exec
/sbin/hotplugon startup around 1000 times.-ben
At what stage? If it's initramfs, then don't have one on initramfs. (Not by default anyway, add a symlink when you're ready to start caring, or write the correct path to /proc/sys/heeeeeeere's_hotplog.)
Failure to exec 1000 times shouldn't take too long. I have shell scripts that fork and exec 1000 times in under a second, and they're actually doing something.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Benjamin LaHaiseQuoted 7 lines · Benjamin LaHaise
Quoted 5 lines · Rob Landley
So no in-kernel filesystem can get this right without help from userspace (even devfs had devfsd), and as soon as you've got a userspace daemon to tell the kernel who is who you might as well do the whole thing there, now that the kernel is exporting everyting _else_ we need to know via /sys and
/sbin/hotplug.
Quoted 5 lines
/sbin/hotplugis suboptimal. Even a pretty fast machine is slowed down pretty significantly by the ~thousand fork and exec that take place during startup. For the most common devices -- common tty, pty, floppy, etc that every system has, this is a plain waste of resources -- otherwise known as bloat.
You mean that distro boot scripts now need to wait for 20 seconds until hotplug has finally handled all the coldplug events so the script can finally slap the IPv4 address onto the interface or start dhcpcd. :-)
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Rob LandleyQuoted 4 lines · Rob Landley
On the busybox list we're currently working out a design for mdev, the micro-udev that'll go into busybox 1.2. So we're thinking about this issue pretty carefully, as we speak. What's the minimal amount of work we can't get away with not doing?
I suggest you take this discussion to the linux-hotplug-devel mailing list, which is the proper place for it. Not this thread about stable kernel series :)
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Greg KH
Quoted 4 lines · Rob Landley
On the busybox list we're currently working out a design for mdev, the micro-udev that'll go into busybox 1.2. So we're thinking about this issue pretty carefully, as we speak. What's the minimal amount of work we can't get away with not doing?
I suggest you take this discussion to the linux-hotplug-devel mailing list, which is the proper place for it. Not this thread about stable kernel series :)
Didn't know there was one. Will do, but probably not today...
Quoted 3 lines
thanks,
greg k-h
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 6 lines · Matthias Andree
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these. That opportunity was missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.
I'm not aware of that policy... maybe I overlooked something?
Quoted 11 lines
This doesn't matter. A kernel that calls itself stable CAN NOT remove features unless they had been critically broken from the beginning. And this level of breakage is a moot point, so removal is not justified.
Who cares what you or I use? It's a commonly acknowledged policy that "stable" releases do not remove features that are good enough for some. Linux 2.6 is not "stable" in this regard.
I guess our definitions of stable (and the degree of stability acceptable) differ.
David
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · David Ranson
Quoted 6 lines · Matthias Andree
So was I. And now what? ipfwadm and ipchains should have been removed from 2.6.0 if 2.6.0 was not to support these. That opportunity was missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.
I'm not aware of that policy... maybe I overlooked something?
Everyone does it, except Linux and GDBM.
Quoted 2 lines
I guess our definitions of stable (and the degree of stability acceptable) differ.
No need to guess, this is quite obvious.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to David RansonQuoted 5 lines · David Ranson
Quoted 1 line · Matthias Andree
So was I. And now what? ipfwadm and ipchains should have been removed
Quoted 8 lines
Quoted 6 lines
from 2.6.0 if 2.6.0 was not to support these. That opportunity was
missed, the removal wasn't made up for in 2.6.1, so the stuff has to stick until 2.8.0.
I'm not aware of that policy... maybe I overlooked something?
Until 2.6, a stable series did not remove existing features, so someone building an rpm or deb package could release it for "2.4.12 or later" and expect it to work.
As a for instance there are people who went to 2.6 and kept their old firwall rules written in ipchains, because they still worked. Now if ipchains are deleted a full rewrite of firewall rules is needed, and that just shouldn't be don't in haste. My personal opinion is that ipfwadm and ipchains should have followed some other features into the night before 2.6.0 ever came out. No one would have gotten a nasty surprise later. I also think that reiser4 is 2.7 material, if there were a 2.7.
I didn't see all that much wrong with the old odd/even model to tell the truth, it wasn't perfect but you knew what you got.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to David RansonQuoted 18 lines · David Ranson
Quoted 3 lines · Adrian Bunk
- support for ipfwadm and ipchains was removed during 2.6
Surely this one had loads of notice though? I was using iptables with 2.4 kernels.
Quoted 3 lines
- devfs support was removed during 2.6
Did this affect many 'real' users?
Quoted 8 lines
Quoted 5 lines
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pendingI don't use any of these. I guess pcmcia-cs may be disruptive for laptop users.
You don't seem to grasp that thousands of people DO use these features, and by removing the features those users are blocked from security, reliability, and performance related changes. And there are a number of other features mentioned
Quoted 6 lines
So far I don't see evidence to suggest huge repeated userspace breakages between Kernel versions that were implied earlier in this thread. Whatever, we aren't going to see any more stable branches without volunteers to do the spadework. As has been pointed out, this won't always be an easy task.
To a large extent I don't think it's a needed task. If new stuff doesn't work that doesn't hurt established uses, it's only when changes like the PCI rethink go in that existing users are impacted. As long as things aren't taken OUT, the current kernel is usefully stable.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 6 lines · Adrian Bunk
Quoted 5 lines · David Ranson
Quoted 3 lines · Steven Rostedt
udev ;)
Quoted 8 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
- support for ipfwadm and ipchains was removed during 2.6
- devfs support was removed during 2.6
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pending
So what you're upset about is the feature removal scheduling mechanism, which usually gives a full year's warning, and the removal patch can be reversed into a feature addition patch you can maintain outside the tree if you really care?
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Ah.. another one, that I was just reminded of again by the umpteenth person posting that their wireless no longer is WPA capable after upgrading from 2.6.12.
Of course, the known solution for that issue is to upgrade to the recently "fixed" latest wpa_supplicant daemon in userspace, since the old one no longer works.
Things like this are all too regular an occurance.
Cheers
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Mark Lord
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Ah.. another one, that I was just reminded of again by the umpteenth person posting that their wireless no longer is WPA capable after upgrading from 2.6.12.
Quoted 5 lines
Of course, the known solution for that issue is to upgrade to the recently "fixed" latest
wpa_supplicantdaemon in userspace, since the old one no longer works.Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new wpa_supplicant package. Don't they bother to test this stuff before they ship it?!?
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 12 lines · Lee Revell
Quoted 11 lines · Mark Lord
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Ah.. another one, that I was just reminded of again by the umpteenth person posting that their wireless no longer is WPA capable after upgrading from 2.6.12.
Of course, the known solution for that issue is to upgrade to the recently "fixed" latest
wpa_supplicantdaemon in userspace, since the old one no longer works.
Quoted 5 lines
Quoted 1 line
Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new
wpa_supplicantpackage. Don't they bother to test this stuff before they ship it?!?
This constant shifting the blame on someone else is becoming offensive.
Diligent maintainers put "INCOMPATIBLE CHANGES" sections up front in their release announcements or notes, that is the upstream maintainer's chance to state "wpa_supplicant version >= 1.2.3 required" and really pass the buck on to the distros. Without such upgrade-required-for:
notes, it's just rude. "We break everything but you need to find out for yourself which..."
Let's not mention that section 2, 7 and 9 manual pages should be maintained by the kernel developers rather than an external maintainer.
If you need a luminous example how release management works, look at Postfix. I don't suggest taking Postfix's development model of printing the diffs and using text marker and pencil, but the "Incompatible changes", "Major changes" in Release Notes, with all the details in a separate changelog, works rather well for distros and direct users.
My suggestion is to build upon the signed-off-by: stuff and require that every incompatible change carry such a RFC2822-header-like line if it is to be merged into baseline, and unconditionally back out all incompatibilities that are later found but not documented.
Perhaps just making people actually write such notes can cut the number of these shipwrecks.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Matthias Andree
This constant shifting the blame on someone else is becoming offensive.
Diligent maintainers put "INCOMPATIBLE CHANGES" sections up front in their release announcements or notes, that is the upstream maintainer's chance to state "
wpa_supplicantversion >= 1.2.3 required" and really pass the buck on to the distros. Without such
upgrade-required-for: notes, it's just rude. "We break everything but you need to find out for
yourself which..."
I'm not trying to shift blame, I am just saying that with their access to a larger hardware and user base the distros are in a much better position to regression test changes than the kernel developers.
And I didn't even mention the cases where the distros just don't do their homework. For example in order to insulate users from internal changes ALSA has a kernel and userspace (alsa-lib) component and both must be upgraded in sync to properly support new hardware. This is common knowledge. But many distros keep shipping kernel upgrades that introduce new ALSA drivers but don't bother to make the kernel upgrade depend on an alsa-lib upgrade, or even to make a newer alsa-lib available.
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 13 lines · Lee Revell
Quoted 11 lines · Matthias Andree
This constant shifting the blame on someone else is becoming offensive.
Diligent maintainers put "INCOMPATIBLE CHANGES" sections up front in their release announcements or notes, that is the upstream maintainer's chance to state "
wpa_supplicantversion >= 1.2.3 required" and really pass the buck on to the distros. Without such
upgrade-required-for: notes, it's just rude. "We break everything but you need to find out for
yourself which..."
Quoted 3 lines
I'm not trying to shift blame, I am just saying that with their access to a larger hardware and user base the distros are in a much better position to regression test changes than the kernel developers.
You just described what shifting burden or blame means.
Are you seriously saying it's the distributors' fault for not trying the random monkey patch on end users machines?
Heck, SUSE 9.2 ate a complete server because SUSE (they take the blame) didn't manage to (1) notice in time, (2) therefore package a CRITICAL (as in causes data corruption) MegaRAID bugfix. Do you really want such things to happen as intrinsic part of the kernel development? Do the upstream gurus such as Linus and Andrew want that? If so, they can say so and we'll see the companies running for their sheer lives and putting their money into other kernels.
BSD makes it only easier to provide binary modules, because you don't even have to discuss with anyone if it's derived work or not, you can just embrace, extend and lock the beast up and everyone in.
Quoted 8 lines
And I didn't even mention the cases where the distros just don't do their homework. For example in order to insulate users from internal changes ALSA has a kernel and userspace (alsa-lib) component and both must be upgraded in sync to properly support new hardware. This is common knowledge. But many distros keep shipping kernel upgrades that introduce new ALSA drivers but don't bother to make the kernel upgrade depend on an alsa-lib upgrade, or even to make a newer alsa-lib available.
Major distros usually aim for small and well-audited changes in order not to make things worse, at least where end-user support is concerned.
Given the development pace and the ridiculous policy which is effectively "you may break everything in the two weeks after release, and we'll collect those fixes that come in until Linus's machine works and ship without the rest".
Basically, no-one should have permission to touch any core parts, except for fixes, until 2.7. Yes, that means going back to older models. Yes, that means that the discussions will start all over. And yes, that means that the cool stuff has to wait. Solution: release more often.
I'm so bold as to claim that a new minor release every 6 months with a tight "only fixes allowed as core changes" policy would satisfy many. Of course you cannot break the binary driver of the day that way, but it also means fewer chances to break NFS, XFS, MegaRAID and whatnot.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Matthias Andree:
Quoted 4 lines
Basically, no-one should have permission to touch any core parts, except for fixes, until 2.7. Yes, that means going back to older models. Yes, that means that the discussions will start all over. And yes, that means that the cool stuff has to wait. Solution: release more often.
Would this alone change much? I think what we really want is that our favorite branch (whatever it is) gets critical fixes forever (well, maybe one or two years, but this is forever). This is a bit unrealistic because everyone has a slightly different branchpoint. Releasing more often doesn't change that, really.
In the security area, I think there is enough experience out there to collect data which would help each local branch maintainer to install the relevant fixes. But for general development, this seems to be infeasible, unless you focus your software architecture on this purpose (which is probably a terrible idea to do for kernel development).
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Florian Weimer
* Matthias Andree:
Quoted 4 lines
Basically, no-one should have permission to touch any core parts, except for fixes, until 2.7. Yes, that means going back to older models. Yes, that means that the discussions will start all over. And yes, that means that the cool stuff has to wait. Solution: release more often.
Quoted 5 lines
Would this alone change much? I think what we really want is that our favorite branch (whatever it is) gets critical fixes forever (well, maybe one or two years, but this is forever). This is a bit unrealistic because everyone has a slightly different branchpoint. Releasing more often doesn't change that, really.
Maybe that is what is needed. A branch that all can use. Have every 5 or so 2.6.x become a "stable" branch. Where distributions and users can work together on keeping it stable. The rules to modifying such a branch would pretty much stay with what it already takes to modify the current 2.6.x.y branch. If you want a feature, you must either take the latest "unstable" 2.6.x branch or wait for the next "stable" 2.6.x branch to merge.
Now who should chose which version the "stable" branch should be? Well, we could just say ever 5 branches will become one, or if we have a "F*cked up" branch (really bad bug made it in), then we can skip it and go to the 6th to branch.
Perhaps, we could start out having Greg and Chris just concentrate on every fifth branch instead of every one, and that way the stability will last much longer. Again, if you want the latest functionality, you go with the latest "unstable" release, or wait for the next stable. Since these releases come out about every month or two, waiting 5 releases will last for almost a year.
For this to work, the normal releases would just continue like normal. And just the marked branch will become stable. This may be similar to what Linus formally proposed. Where he had every odd revision be unstable, and every even stable. What I'm suggesting would not make the stable branch stable by what goes into it. It's just that those are the branches that would have the .y version. And then we could ignore the other branches instead.
This idea combines pretty much the idea of the 2.7 with the current 2.6.x.y. Actually it is more like the 2.7 approach, but it's hidden :-) The problem with 2.7 is that nobody tests it, and it takes too long to go from 2.6 to 2.8. My method here hides that fact. You just basically say "here's the stable version" and let it fork. Continue on with the 2.6.x and when you think too many people are using the last stable version, and are not testing the current branch, just release the new "stable", and pull everyone back in.
-- Steve
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Steven Rostedt
Perhaps, we could start out having Greg and Chris just concentrate on every fifth branch instead of every one, and that way the stability will last much longer.
Ah, belling the cat.
Hint: Any plan in a volunteer community that starts with "$BUSY_PEOPLE should do $THIS" fails. Any plan that starts with "I could do $THIS" at least has a chance.
This is not limited to open source, by the way...
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Rob Landley
Quoted 3 lines · Steven Rostedt
Perhaps, we could start out having Greg and Chris just concentrate on every fifth branch instead of every one, and that way the stability will last much longer.
Ah, belling the cat.
:)
Quoted 4 lines
Hint: Any plan in a volunteer community that starts with "$BUSY_PEOPLE should do $THIS" fails. Any plan that starts with "I could do $THIS" at least has a chance.
Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...) I was trying to get them to only maintain 2.6.x.y (x => 11, 12, 13, 14, 20, 25, ...)
So maybe it would actually be easier. But I'm sure they wouldn't be fooled, since the longer you maintain a fork, the harder it becomes.
I was just making a suggestion, so that if someone else thought it was a good idea, they could do it. I personally don't need such a beast, since I would just stay with the latest 2.6.x anyway. Since I have that luxury.
Quoted 2 lines
This is not limited to open source, by the way...
Yep, I know that.
-- Steve
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Steven Rostedt:
Quoted 5 lines
Quoted 3 lines
Hint: Any plan in a volunteer community that starts with "$BUSY_PEOPLE should do $THIS" fails. Any plan that starts with "I could do $THIS" at least has a chance.
Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...)
I think the 2.6.x.y series is no longer maintained once 2.6.x+1 has been released for some time (surely after 2.6.x+2).
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Florian Weimer
Quoted 2 lines
Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...)
I think the 2.6.x.y series is no longer maintained once 2.6.x+1 has been released for some time (surely after 2.6.x+2).
The same can still go for this, but instead of stopping at 2.6.x+2 we could stop at 2.6.x+6 (or +5), and just not care about 2.6.x+[1-4]. But that would be strong enough for those that would like the stable branch to maintain it themselves. Currently it'l hard to pick a 2.6.x that you want to stay with since the 2.6.x.y is stopped right after 2.6.x+1 is out. But if not all 2.6.x has a .y, then that would focus more distrobutions or whatever to pick the same one to support.
Oh well, I'm just spitting out a bunch of lip service here. It actually seems interesting to try, and if I actually had a need to do this, I would. But right now my focus is elsewhere.
Cheers,
-- Steve
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Steven Rostedt
Quoted 4 lines · Florian Weimer
Quoted 1 line
Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...)
I think the 2.6.x.y series is no longer maintained once 2.6.x+1 has been released for some time (surely after 2.6.x+2).
Quoted 7 lines
The same can still go for this, but instead of stopping at 2.6.x+2 we could stop at 2.6.x+6 (or +5), and just not care about 2.6.x+[1-4]. But that would be strong enough for those that would like the stable branch to maintain it themselves. Currently it'l hard to pick a 2.6.x that you want to stay with since the 2.6.x.y is stopped right after 2.6.x+1 is out. But if not all 2.6.x has a .y, then that would focus more distrobutions or whatever to pick the same one to support.
OK, let's step back and...
- People work on Linux (or whatever other stuff) because it is /fun/ and /exciting/.
- People who don't actively work on a piece of code won't know it intimately, so they'll make mistakes when looking for bugs/fixes
- There is little excitement in just fixing bugs in frozen code, developers will just migrate elsewhere if there is no fun here
- "Experimental versions" are only run by masochists and bored people who need fireworks now and then to know they are still alive. End users don't even consider them, when the software is stable enough for the crazier ones to unleash on the world as "stable" is when the bugs surface (Remember the disaster of the early 2.4s? Ever heard of "Let's wait for X.<even>.10 or so, by then it will be stable enough for everyday use"?).
- End users /don't/ test "prereleases", they deem them too risky... so the "releases" usually ship with lethal bugs for some people. Decreeing that each 5th (or whatever) release will be "golden" will just get people to skip all the others, resulting in /much more/ serious bugs in the end
- Backporting new features into a different setting is almost as hard, or perhaps much harder, than developing said features in the first place. Backpòrting bug fixes is a thankless job.
- Distributions /do/ have the infrastructure in place to collect bug reports and correlate them with hardware and software configurations, moreover they work with /one/ (or at most a few) kernel configuration, not with the almost random assortment of kernel configurations you'll find with self-built ones. They also have the (paid) manpower to extract conclusions from the above data.
- If all distributions work from approximately the same base, much duplicate/wasted work (yes, backporting is mostly wasted effort IMHO) is saved.
- Tools for kernel work are /much/ better now, it is reasonable to maintain patches out-of-vanilla and keep the base syncronized with the standard kernel source. Lots of people do so now, when it previously was a full-time job for the incredibly productive gnome community known collectively as "Alan Cox" to do so. There is thus much less need for "odd" series in which to integrate new stuff.
All of the above led to the current kernel development model. Users might not be too happy about it, but the key developers are. And the important people, the ones you /have/ to keep happy in the OSS development model, aren't the users. Besides, everybody moaning about the new development model want something impossible: Fast development, timely integration of support for newest hardware, while bug free all the time. Won't ever happen.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Steven RostedtQuoted 7 lines · Steven Rostedt
Quoted 3 lines
Hint: Any plan in a volunteer community that starts with "$BUSY_PEOPLE should do $THIS" fails. Any plan that starts with "I could do $THIS" at least has a chance.
Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...) I was trying to get them to only maintain 2.6.x.y (x => 11, 12, 13, 14, 20, 25, ...)
That's still "trying to get them" rather than "I could"...
Quoted 2 lines
So maybe it would actually be easier. But I'm sure they wouldn't be fooled, since the longer you maintain a fork, the harder it becomes.
And the number exponentially increases (2.6.x+1.y, 2.6.x+2.y, all at the same time...)
No, I pestered them a while back about possibly doing a 2.6.x.y+1 to flush their patch queue before doing a 2.6.x+1.1, and they seem more receptive to the idea now. But then backporting 2.6.x+1.y to 2.6.x becomes your job...
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Steven Rostedt* Steven Rostedt:
Quoted 7 lines
Quoted 5 lines
Would this alone change much? I think what we really want is that our favorite branch (whatever it is) gets critical fixes forever (well, maybe one or two years, but this is forever). This is a bit unrealistic because everyone has a slightly different branchpoint. Releasing more often doesn't change that, really.
Maybe that is what is needed. A branch that all can use.
There isn't a single one. Even for Debian, it was a hard struggle to get sown to just two (or three?). Now try that across distributions, or for people who own choosy hardware. (I once had to deal with a box which didn't like anything else except 2.6.0-test9. I believe it's still running this version, maybe slightly patched.)
Quoted 6 lines
Have every 5 or so 2.6.x become a "stable" branch. Where distributions and users can work together on keeping it stable. The rules to modifying such a branch would pretty much stay with what it already takes to modify the current 2.6.x.y branch. If you want a feature, you must either take the latest "unstable" 2.6.x branch or wait for the next "stable" 2.6.x branch to merge.
In essence, this is just a slower version of the current model. It won't change that much, unless the speed of the development cycle (and its phase) matches your needs, which is unlikely. Security bugs would still be discovered at about the same rate.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Florian WeimerQuoted 7 lines · Florian Weimer
* Matthias Andree:
Quoted 4 lines
Basically, no-one should have permission to touch any core parts, except for fixes, until 2.7. Yes, that means going back to older models. Yes, that means that the discussions will start all over. And yes, that means that the cool stuff has to wait. Solution: release more often.
Quoted 5 lines
Would this alone change much? I think what we really want is that our favorite branch (whatever it is) gets critical fixes forever (well, maybe one or two years, but this is forever). This is a bit unrealistic because everyone has a slightly different branchpoint. Releasing more often doesn't change that, really.
Releasing minor releases more often and enforcing "don't touch unless you must" policy would create such synchronization point and a branch where everyone could safely hop between releases.
Quoted 6 lines
In the security area, I think there is enough experience out there to collect data which would help each local branch maintainer to install the relevant fixes. But for general development, this seems to be infeasible, unless you focus your software architecture on this purpose (which is probably a terrible idea to do for kernel development).
I don't think focusing the kernel on code quality and security is wrong though. The actual problem we've seen from postings by Lee and others is that the burden of test is shifted to the distros and their QA teams so that effectively everyone is free to break things at will, downstream QA will fix it anyways.
This however doesn't work, and the problem here is the propagation delay. At the time the end user sees a problem with his kernel, the upstream has already abandoned the 2.6.X.Y stable branch the distro was based on, and upstream is at 2.6.X+2 or even farther ahead. What is actually needed is to enclose this end user system in the tests run before further changes in the same area. And as udev etc. need to change, a simple test if the current kernel works means updating some user space packages, hotplug, modutils (OK this was 2.5), udev, whatever, and what's even worse, if that doesn't help or breaks other things. Going back may not even work through the packaging system because the old kernel version may not have a "udev <= N" dependency either...
So before this can work, the actual package maintenance systems such as yum, yast, dpkg, apt and rpm will need to support what Emacs Lisp calls excursions. It means, snapshot the packages and revert to the same set later.
Even if this were solved and excursions were cheap, it would still not solve the time skew bug report and upstream fixes...
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lee RevellQuoted 6 lines · Lee Revell
Quoted 2 lines
Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new
wpa_supplicantpackage. Don't they bother to test this stuff before they ship it?!?
I've broken stuff by upgrading glibc, upgrading X, upgrading KDE...
Upgrading the kernel is safer? (Anybody remember 2.4.11-dontuse?)
Yay, modular component-based design. We have standard interfaces so that stuff mostly works when you swap out different versions (or entire different components). This is cool.
But if such interfaces were actually sufficient to specify all the functionality you actually want to use, why would you ever need to upgrade a component implementing that interface to a new version?
The real problem people are seeing is that the rate of change has increased. Linus used to be a hell of a bottleneck, and this stopped being the case when source control systems took over a lot of the patch tracking, ordering, batching, and integration burden.
Automating the patch flow allowed entire subsystems to be effectively delegated (and thus the "lieutenants" layer formed and was formalized), and each of _them_ is now doing as much work as Linus used to do.
And _that_ is why there is no longer any point in -devel forks, because Linus is now fielding as many patches in a month as he used to in a year. That means in every 3 months the Linux kernel undergoes as much development (in terms of patches merged and lines of code changed) as an entire -devel series used to do. (Somebody confirm the numbers, these are approximations.)
There's no point in launching a fork that's only expected to last three months. Hence no -devel fork.
Also, forks are cheaper now. The new source control tools (not just git but quilt and ketchup and so on) allow multiple parallel trees to be trivially integrated. It used to take somebody like Alan Cox all his spare time to maintain a tree and merge with linus, and back then the -ac tree was very special. Now Con Colivas can maintain a tree in his spare time with a day job as an anesthesiologist, and this is _normal_. There are dozens of trees out there feeding into each other, and anybody who wants to can grab the relevant subsystem tree and try it out to make sure that the issue they care about is fixed, and be assured that it'll all flow in to Linus's tree.
What's special about Linus's tree is that it's the point to the wedge. This is the farthest we've advanced, this is your best bet. There's always something wrong with any piece of software, but half the complaints have always been that something is fixed but not merged yet. (Orinoco scanning,
ISDN, ALSA, examples are legion.) That's getting way better.
Now the _new_ class of complaints is that the IPW2200 driver that first got merged was too old. (I noticed this because that's the wireless card in my laptop.) Stop and think about that for a bit. People were used to IPW2200 not being there at all, so they could easily add an external patch. Then 2.6.14 grew partial IPW2200 support, but with an older driver, and people were mad because the external patch they had to add support only applied when the driver wasn't there at all, and it didn't apply over the older version. They were mad that _insufficient_ support showed up.
This is being fixed in 2.6.15. It didn't last long.
The new model is that if the kernel has half what you need, you need to come up with an incremental patch to get it the rest of the way, and submit that. And the up-side is that it'll go in pretty fast now. Yes, the kernel is changing rapidly enough that external patches probably need to be fixed up with every new version. (And if you're using the nvidia driver, this sucks rocks. You were warned.)
The other thing people are complaining about is the deprecation schedule. Notice is posted prominently up to a YEAR before a feature gets yanked. Apparently, they want to upgrade to the new version when it comes out, but don't want to read the instructions for this version (X went away), or the warnings about upcoming versions...
Possibly if we had a CHANGES file at the root level of the source mentioning
A) What's new in this version.
B) What's slated for next version (DEPRECATION COMING).
C) What was new in the last version, in case you missed it.
A combination of Documentation/feature-removal-schedule.txt and
http://wiki.kernelnewbies.org/LinuxChanges, with emphasis on userspace tools known to be impacted.
Quoted 1 line
Lee
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 17 lines · Rob Landley
Quoted 5 lines · Lee Revell
Quoted 1 line
Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new
wpa_supplicantpackage. Don't they bother to test this stuff before they ship it?!?I've broken stuff by upgrading glibc, upgrading X, upgrading KDE...
Upgrading the kernel is safer? (Anybody remember 2.4.11-dontuse?)
Yay, modular component-based design. We have standard interfaces so that stuff mostly works when you swap out different versions (or entire different components). This is cool.
But if such interfaces were actually sufficient to specify all the functionality you actually want to use, why would you ever need to upgrade a component implementing that interface to a new version?
Quoted 7 lines
The real problem people are seeing is that the rate of change has increased. Linus used to be a hell of a bottleneck, and this stopped being the case when source control systems took over a lot of the patch tracking, ordering, batching, and integration burden.
Automating the patch flow allowed entire subsystems to be effectively delegated (and thus the "lieutenants" layer formed and was formalized), and each of _them_ is now doing as much work as Linus used to do.
And _that_ is why there is no longer any point in -devel forks, because Linus is now fielding as many patches in a month as he used to in a year. That means in every 3 months the Linux kernel undergoes as much development (in terms of patches merged and lines of code changed) as an entire -devel series used to do. (Somebody confirm the numbers, these are approximations.)
There's no point in launching a fork that's only expected to last three months. Hence no -devel fork.
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
The other group is the people who use and depend on some feature, be it cryptoloop, 8k stacks, ndiswrapper, ipchains, whatever... which is scheduled for extinction. That's a departure from the way 2.{0,2,4} were done, where adds happened regularly, but features were only deleted in development trees. Deleting features leaves anyone who can't keep their own tree without security fixes. I see that as bed, and a far more important departure from the old model than the speed of new adds.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines
The other group is the people who use and depend on some feature, be it cryptoloop, 8k stacks, ndiswrapper, ipchains, whatever... which is scheduled for extinction.
these are actually 2 groups
1) people who depend on an in-kernel features
2) people who depend on out of kernel / binary modules
treating them as one is not correct or fair to this thread.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Arjan van de Ven
Quoted 3 lines
The other group is the people who use and depend on some feature, be it cryptoloop, 8k stacks, ndiswrapper, ipchains, whatever... which is scheduled for extinction.
Come on, most of those were scheduled for deletion a /long/ time ago.
Quoted 7 lines
these are actually 2 groups
1) people who depend on an in-kernel features
2) people who depend on out of kernel / binary modules
treating them as one is not correct or fair to this thread.
Right.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 6 lines · Bill Davidsen
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
My laptop has an ipw2200 but I can't get it to work in any kernel I built because the kernels I build aren't modular. I hope to be able to work around this someday with a clever enough initramfs (if necessary, moving the initramfs initialization earlier in the boot sequence), but it hasn't made it far enough up my todo list yet.
So whether or not the driver actually works if I could get it initialized is, for me, a moot point.
Quoted 2 lines
The other group is the people who use and depend on some feature, be it cryptoloop, 8k stacks, ndiswrapper, ipchains, whatever... which is
Ndiswrapper isn't a kernel feature. Don't confuse the shark with the remoras.
The only complaint about 8k stacks I've heard is the ndiswrapper people, and 8k isn't actually sufficient for them anyway (_their_ ad-hoc spec guarantees 12k), so they should have been swapping to their own stack all along. They should probably even statically allocate the sucker at boot time and serialize all drivers using it with a semaphore, because I _really_ doubt it's ever been preempt-safe.
Isn't ipchains obsolete since 2.2? it was already deprecated back in 2.4. There has been quite adequate warning on that one, thanks very much.
I'm under the impression the problem with cryptoloop is bad cryptography:
http://lwn.net/Articles/67216/
Anybody actually using cryptography with an expoitable weakness needs all the wake-up calls they can get. This is _not_ a case where you want to support old broken crap, that defeats the whole purpose of using cryptography in the first place.
Especially the cryptoloop removal was an intentional decision that the kernel developers made. People raised their objections at the time, and these were taken into consideration when making the decision:
http://kerneltrap.org/node/2433
Re-raising the same objections over and over again when they've already been aired, considered, and rejections is called "whining".
Quoted 3 lines
scheduled for extinction. That's a departure from the way 2.{0,2,4} were done, where adds happened regularly, but features were only deleted in development trees.
If features were really were deleted in development trees, devfs and ipchains never would have made it through 2.4. So you're talking about an idealized version fo the past that doesn't match what people actually did back then.
Quoted 2 lines
Deleting features leaves anyone who can't keep their own tree without security fixes.
Security fixes are a separate issue.
I asked for one more security fix to flush the pending fixes queue a while ago:
http://seclists.org/lists/linux-kernel/2005/Nov/4187.html
On Saturday, stable series co-maintainer Chris Wright decided it might be worth a try:
http://seclists.org/lists/linux-kernel/2005/Dec/0740.html
Quoted 3 lines
About the only thing I think is helpful in this case is perhaps
one extra -stable cycle on the last branch when newest branch is released (basically flush the queue). That much I'm willing to do in -stable.
To which I replied (and again I quote), "Yay, rah, cool!".
This gives you a trail of breadcrumbs to follow. There are a series of incremental patches (which may have to be fixed up to apply) that address the known security-specific issues.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 8 lines · Rob Landley
Quoted 6 lines · Bill Davidsen
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
Quoted 5 lines
My laptop has an ipw2200 but I can't get it to work in any kernel I built because the kernels I build aren't modular. I hope to be able to work around this someday with a clever enough initramfs (if necessary, moving the initramfs initialization earlier in the boot sequence), but it hasn't made it far enough up my todo list yet.
Well, building modular kernel for a test is not *that* much work. Anyway, if you are going to fix it, fix it properly (by delayed firmware loading) -- initrd hacks are good for you but unusable for anyone else.
Pavel
Signature · 1 line
Thanks, Sharp!
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 15 lines · Pavel Machek
Quoted 8 lines · Rob Landley
Quoted 6 lines · Bill Davidsen
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
Quoted 5 lines
My laptop has an ipw2200 but I can't get it to work in any kernel I built because the kernels I build aren't modular. I hope to be able to work around this someday with a clever enough initramfs (if necessary, moving the initramfs initialization earlier in the boot sequence), but it hasn't made it far enough up my todo list yet.
Quoted 4 lines
Well, building modular kernel for a test is not *that* much work. Anyway, if you are going to fix it, fix it properly (by delayed firmware loading) -- initrd hacks are good for you but unusable for anyone else.
I don't see why that's any less usable than using udev from initramfs to find your root partition.
There is an interesting licensing issue, creating a linux kernel image that contains an initramfs that contains binary only firmware. I can happily generate one here and not care, but does distributing such a kernel violate the GPL?
It's probable that the "early userspace" mechanism is a clearly defined API. We documented the heck out of the format, it cpio was already a standard anyway. The binaries that are in there call the normal userspace API (syscall/ioctl/procfs etc) that is an established strong barrier to being a derived work. So it's possible that putting those binaries in initramfs counts as "mere aggregation". (If you had the kernel and the firmware in an ISO image, that's the same as being different files on the same CD, and definitely mere aggregation. As separate files in the same tarball, it's closer but functionally equivalent and probably still just aggregation. Probably. Different elf sections in the same binary is one more step, but depending on the intent the analogy could still hold...)
I can see distributors shying the heck away from it anyway, and wanting to keep things in _seperate_files_. And I can entirely understand that. This means if initramfs is going to contain firmware, the option of having it be a separate file like initrd for legal reasons is a darn good idea.
Query: if you tell lilo or grub that it has an initrd but feed it a gzipped cpio image, will the kernel figure everything out and initialize initramfs from that appropriately?
Quoted 1 line
Pavel
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 16 lines · Rob Landley
Quoted 15 lines · Pavel Machek
Quoted 13 lines · Rob Landley
Quoted 6 lines · Bill Davidsen
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
My laptop has an ipw2200 but I can't get it to work in any kernel I built because the kernels I build aren't modular. I hope to be able to work around this someday with a clever enough initramfs (if necessary, moving the initramfs initialization earlier in the boot sequence), but it hasn't made it far enough up my todo list yet.
Quoted 7 lines
Quoted 4 lines
Well, building modular kernel for a test is not *that* much work. Anyway, if you are going to fix it, fix it properly (by delayed firmware loading) -- initrd hacks are good for you but unusable for anyone else.
I don't see why that's any less usable than using udev from initramfs to find your root partition.
Why use udev from initramfs? Just teach ipw2200 to load firmware late. Don't load firmware when ipw2200 is initialized, load it only when someone attempts to talk to your ipw2200. At that time, you should have userland already.
Pavel
Signature · 1 line
Thanks, Sharp!
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 23 lines · Pavel Machek
Quoted 22 lines · Rob Landley
Quoted 20 lines · Pavel Machek
Quoted 9 lines · Rob Landley
Quoted 7 lines · Bill Davidsen
Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.
Quoted 5 lines
My laptop has an ipw2200 but I can't get it to work in any kernel I built because the kernels I build aren't modular. I hope to be able to work around this someday with a clever enough initramfs (if necessary, moving the initramfs initialization earlier in the boot sequence), but it hasn't made it far enough up my todo list yet.
Well, building modular kernel for a test is not *that* much work. Anyway, if you are going to fix it, fix it properly (by delayed firmware loading) -- initrd hacks are good for you but unusable for anyone else.
Quoted 4 lines
Quoted 2 lines
I don't see why that's any less usable than using udev from initramfs to find your root partition.
Why use udev from initramfs?
I don't, but I do use a script that mknods the real root's node based on running "find" against /sys to locacate the appropriate device name and then finding the major/minor numbers there.
This has nothing whatsoever to do with ipw2200. It just means I'm not using the in-kernel root-finder code.
Quoted 1 line
Just teach ipw2200 to load firmware late.
That's now how I'd fix this. If you want to fix it this way, be my guest.
Quoted 3 lines
Don't load firmware when ipw2200 is initialized, load it only when someone attempts to talk to your ipw2200. At that time, you should have userland already.
Or I could move initramfs extraction earlier in the boot sequence and never have to modify any _other_ drivers that want firmware in order to be able to make them work too, rather than playing whack-a-mole teaching drivers I don't care about how to hold off on wanting firmware.
Quoted 1 line
Pavel
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Hi!
Quoted 13 lines
Quoted 1 line
Why use udev from initramfs?
I don't, but I do use a script that mknods the real root's node based on running "find" against /sys to locacate the appropriate device name and then finding the major/minor numbers there.
This has nothing whatsoever to do with ipw2200. It just means I'm not using the in-kernel root-finder code.
Quoted 1 line
Just teach ipw2200 to load firmware late.
That's now how I'd fix this. If you want to fix it this way, be my guest.
Quoted 8 lines
Quoted 3 lines
Don't load firmware when ipw2200 is initialized, load it only when someone attempts to talk to your ipw2200. At that time, you should have userland already.
Or I could move initramfs extraction earlier in the boot sequence and never have to modify any _other_ drivers that want firmware in order to be able to make them work too, rather than playing whack-a-mole teaching drivers I don't care about how to hold off on wanting firmware.
Except that whack-a-mole is a right thing to do here, and that initramfs movement is unlikely to make it into mainline.
Pavel
Signature · 1 line
Thanks, Sharp!
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 8 lines · Pavel Machek
Quoted 4 lines
Or I could move initramfs extraction earlier in the boot sequence and never have to modify any _other_ drivers that want firmware in order to be able to make them work too, rather than playing whack-a-mole teaching drivers I don't care about how to hold off on wanting firmware.
Except that whack-a-mole is a right thing to do here, and that initramfs movement is unlikely to make it into mainline.
Pavel
Let me guess: for licensing reasons?
The option to keep initramfs in a separate file (like initrd) should, in theory, make that a moot point...
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 11 lines · Rob Landley
Quoted 8 lines · Pavel Machek
Quoted 4 lines
Or I could move initramfs extraction earlier in the boot sequence and never have to modify any _other_ drivers that want firmware in order to be able to make them work too, rather than playing whack-a-mole teaching drivers I don't care about how to hold off on wanting firmware.
Except that whack-a-mole is a right thing to do here, and that initramfs movement is unlikely to make it into mainline.
PavelLet me guess: for licensing reasons?
Wrong. "Fix the driver" is easier to get into the kernel than "change the boot sequence".
Signature · 1 line
Thanks, Sharp!
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
In reply to Rob LandleyRob Landley <[email protected]> wrote:
[...]
Quoted 4 lines
There is an interesting licensing issue, creating a linux kernel image that contains an initramfs that contains binary only firmware. I can happily generate one here and not care, but does distributing such a kernel violate the GPL?
Some distributions (e.g. INSERT) ship a CD image with ipw2x00 firmware.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
In reply to Rob LandleyQuoted 3 lines · Rob Landley
Query: if you tell lilo or grub that it has an initrd but feed it a gzipped cpio image, will the kernel figure everything out and initialize initramfs from that appropriately?
Yes, I've been booting my laptop this way (using GRUB) since 2.6.7 or so.
Signature · 4 lines
Ben Slusky | It was only after their population [email protected] | of 50 mysteriously shrank to eight [email protected] | that the other seven dwarfs began PGP keyID ADA44B3B | to suspect Hungry.
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 6 lines · Ben Slusky
Quoted 3 lines · Rob Landley
Query: if you tell lilo or grub that it has an initrd but feed it a gzipped cpio image, will the kernel figure everything out and initialize initramfs from that appropriately?
Yes, I've been booting my laptop this way (using GRUB) since 2.6.7 or so.
Sigh, gotta update the docs again... :)
Do you need to compile initrd support in for this to work, or just tell grub/lilo to do its' thing? (I can answer this one myself when I get around to setting up another test environment...)
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]
Quoted 5 lines · Bill Davidsen
Rob Landley wrote:
I haven't tried that, since I use initrd files and have the kernel support, but I confess I don't see the cpio as being easier to create. You presumably still want to include the modules from the fresh built kernel, so creating a new cpio file would seem needed for most people.
cpio files are somewhat easier to create in that they can created by an unprivileged user. Most of the steps in making an initrd can only be done by root.
Signature · 4 lines
Ben Slusky | You must be smarter than [email protected] | <= this stick to ride the [email protected] | internet. PGP keyID ADA44B3B
Re: ipw2200
Quoted 8 lines · Ben Slusky
Quoted 4 lines
I confess I don't see the cpio as being easier to create. You presumably still want to include the modules from the fresh built kernel, so creating a new cpio file would seem needed for most people.
cpio files are somewhat easier to create in that they can created by an unprivileged user. Most of the steps in making an initrd can only be done by root.
Initrds are also annoying because you have to guess/calculate a "disk" size big enough to hold all the contents and inevitably waste some space providing a margin for error.
Initrd seems at best a kind of kludge anyway; initramfs is just all-around a cleaner concept.
-Miles
Signature · 2 lines
`To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Rob LandleyQuoted 11 lines · Rob Landley
I'm under the impression the problem with cryptoloop is bad cryptography:
http://lwn.net/Articles/67216/Anybody actually using cryptography with an expoitable weakness needs all the wake-up calls they can get. This is _not_ a case where you want to support old broken crap, that defeats the whole purpose of using cryptography in the first place.
Especially the cryptoloop removal was an intentional decision that the kernel developers made. People raised their objections at the time, and these were taken into consideration when making the decision:
http://kerneltrap.org/node/2433Re-raising the same objections over and over again when they've already been aired, considered, and rejections is called "whining".
Repeating the same information over and over until it sinks in is called "rote learning." The question is not if cryptoloop is perfect, every crypto seems to fail eventually, recently md5 was cracked, etc. But people have used cryptoloop now, and removing it from the kernel will lock them out of their own data, or prevent them from moving forward. There's no replacement for cryptoloop, so I can't just reconfigure X and still read my 147 DVDs full of business data, or access the current data on 34 laptops around the country.
In most cases CL is not expected to protect against goverment agencies but rather stolen laptops in airports (yes the pros have added MacOS and Linux to their business model) or the occasional lost DVD in the mail. Removing CL is not a hell of a lot better morally than these viruses which encrypt your data and then hold it for ransom, with the price being doing without security fixes in future kernels.
Given that CL has minimal (essentially no) maintenence cost, I wish the ivory tower developers could understand that real people have invested real money in it, and real data in the technology. Since there is no alternative solution offered, CL is far better than no crypto at all, and I wish there were a few more developers who had experience working in the real word.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Bill Davidsen
Quoted 3 lines · Rob Landley
Re-raising the same objections over and over again when they've already been aired, considered, and rejections is called "whining".
Quoted 8 lines
Repeating the same information over and over until it sinks in is called "rote learning." The question is not if cryptoloop is perfect, every crypto seems to fail eventually, recently md5 was cracked, etc. But people have used cryptoloop now, and removing it from the kernel will lock them out of their own data, or prevent them from moving forward. There's no replacement for cryptoloop, so I can't just reconfigure X and still read my 147 DVDs full of business data, or access the current data on 34 laptops around the country.
Bill, I still don't think your complaints are justified.
You're only "locked out of your own data" if you knowingly upgrade to a kernel that doesn't support cryptoloop. Nobody's forcing you to do that.
The kernel developers owe *nothing* to J. Random User. They are either doing what they do for their own reasons (the "fun" of it), or being paid by an organization with specific objectives (even if, in Linus' case, the objective is just "make the best kernel possible, based on your judgement and that of people you trust").
That said, of course none of them want to break things unnecessarily. But they make technical decisions, with the goal of having the best kernel, that do sometimes have painful consequences. You're free, of course, to disagree with those decisions and maintain your own kernel.
They don't owe you security fixes either. Sorry, but that's the way it is. We're all lucky that they take security very seriously and respond quickly to problems.
Quoted 6 lines
In most cases CL is not expected to protect against goverment agencies but rather stolen laptops in airports (yes the pros have added MacOS and Linux to their business model) or the occasional lost DVD in the mail. Removing CL is not a hell of a lot better morally than these viruses which encrypt your data and then hold it for ransom, with the price being doing without security fixes in future kernels.
That last sentence is crap.
You're free to backport security fixes to cryptoloop-supporting kernels forever, or pay someone to do so. Or maintain a cryptoloop patch against current kernels, or pay someone to do so. Or write a converter for cryptoloop data to whatever's currently in the kernel, or pay someone to do so.
Quoted 6 lines
Given that CL has minimal (essentially no) maintenence cost, I wish the ivory tower developers could understand that real people have invested real money in it, and real data in the technology. Since there is no alternative solution offered, CL is far better than no crypto at all, and I wish there were a few more developers who had experience working in the real word.
If you include a crypto solution in the mainstream kernel, you're in some sense endorsing its security. If that solution has known weaknesses, I can understand wanting to either fix it or rip it out. Crypto is hard enough to get right as it is.
Your "ivory tower" statement is really condescending. Linux is way past the stage where college students were the main contributors (if it ever was so after Linus graduated). and a great majority of developers now are paid to work on the kernel. There are probably very few of them that don't have at least a little sysadmin experience.
If you've invested money and put important data in a system, and you haven't contracted with anyone to support that system, supply security fixes, and make sure it does what you want it to do, who's the fool?
Basically, you're complaining about something you get *for free* that represents millions of hours of work, because it doesn't work quite the way you want it to, when you have perfect freedom to make it meet your needs by putting in your own time, effort and/or money.
-Doug
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Douglas McNaught
The kernel developers owe *nothing* to J. Random User. They are either doing what they do for their own reasons (the "fun" of it), or being paid by an organization with specific objectives (even if, in Linus' case, the objective is just "make the best kernel possible, based on your judgement and that of people you trust").
That's not a good argument. I don't think Bill has a good argument either, but this isn't one.
The kernel developers have very good reasons for what they're doing, and ultimately they believe that what they're doing is in the best long-term interests of the users. Bill has objections based on the short-term interests of users. The kernel developers are saying that looking after the short-term interests of the users is the distros' problems, while they focus on the long-term and the big picture.
Both are doing what they believe to be in the best interests of the users. Bill believes (and keeps uselessly repeating) that the kernel developers should pay more attention to short-term interests. The whole "stable series" vs "continuous development" is about short-term interests vs long-term interests.
Overall, development of new technology (and adoption of new technology) goes faster when it's continuous than when you have large discontinuous jumps. You find problems faster, and you find them one at a time when it's easy to isolate what's wrong rather than receiving three years of development in one gulp and experiencing fifteen different failures all at once. Problems are more frequent, but they're smaller and simpler and easier to diagnose and easier to fix. User can _cope_ with a higher rate of change when it comes in smaller chunks. The learning curve isn't a cliff.
Quoted 1 line
They don't owe you security fixes either.
Actually, they seem to think they do. They're quite dilligent about providing security fixes. But the security fixes they give are part of the ongoing development process. Separating them out and backporting them to previous versions is your problem, and if you don't feel up to it they point you to distributions, which will do that for you.
So there are two different ways you can get the fixes. (Upgrade, or use a distro maintained kernel.) Some people think they're owed a third way, and want somebody else to provide it for them.
Quoted 1 line
Your "ivory tower" statement is really condescending.
*shrug* This whole thread is basically people bitching about what other people should do, instead of banding together and giving it a try themselves. It started condescending. In the absence of constructive suggestions or anyone actually doing real work rather than merely bitching about the state of the world, I think most of the developers have written off the whiners with a silent "sucks to be you" and moved on...
(I do hope we get the "buffer flush" dot-releases though. That would be nice.)
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Douglas McNaughtQuoted 24 lines · Douglas McNaught
Quoted 9 lines · Bill Davidsen
Quoted 5 lines · Rob Landley
Re-raising the same objections over and over again when they've already been aired, considered, and rejections is called "whining".
Quoted 10 lines
Repeating the same information over and over until it sinks in is called "rote learning." The question is not if cryptoloop is perfect, every crypto seems to fail eventually, recently md5 was cracked, etc. But people have used cryptoloop now, and removing it from the kernel will lock them out of their own data, or prevent them from moving forward. There's no replacement for cryptoloop, so I can't just reconfigure X and still read my 147 DVDs full of business data, or access the current data on 34 laptops around the country.
Quoted 3 lines
Bill, I still don't think your complaints are justified.
I never expected anyone to admit they were wrong, so that doesn't surprise me...
Quoted 5 lines
You're only "locked out of your own data" if you knowingly upgrade to a kernel that doesn't support cryptoloop. Nobody's forcing you to do that.
Are you endorsing ignoring security fixes? Of course you're forced to if you are trying to be secure. If there were a replacement for cryptoloop that wouldn't be a problem. But saying that CL must go because it isn't perfect is like saying that you shouldn't lock your window because someone could still break it and get in.
Quoted 7 lines
The kernel developers owe *nothing* to J. Random User. They are either doing what they do for their own reasons (the "fun" of it), or being paid by an organization with specific objectives (even if, in Linus' case, the objective is just "make the best kernel possible, based on your judgement and that of people you trust").
A little later you say that most of the developers are paid for working on Linux. Just who is the ultimate source of that funding if not the random user? Almost all of it comes from people who lack the ability to maintain the kernel, one way or the other. If kernel features are left to the vendors you encourage fragmentation, and all you have to do is look at BSD to see what a success that is.
What Linux has going over Windows is choice... the ability to configure WITHOUT having to depend on the judgement of someone else. And when that judgement is to remove a feature which has no replacement, in which uses have made an investment, then the choice is gone.
Quoted 6 lines
That said, of course none of them want to break things unnecessarily. But they make technical decisions, with the goal of having the best kernel, that do sometimes have painful consequences. You're free, of course, to disagree with those decisions and maintain your own kernel.
Why waste electrons on statments like that. Yes, I could do that, but the average users can't, and after maintaining GECOS, and MULTICS, and supporting BSD installations and writing a realtime control o/s, I certainly don't have the slightest interest in spending my time doing that. Effectively anything not in a kernel.org kernel is going to die.
Quoted 15 lines
They don't owe you security fixes either. Sorry, but that's the way it is. We're all lucky that they take security very seriously and respond quickly to problems.
Quoted 8 lines
In most cases CL is not expected to protect against goverment agencies but rather stolen laptops in airports (yes the pros have added MacOS and Linux to their business model) or the occasional lost DVD in the mail. Removing CL is not a hell of a lot better morally than these viruses which encrypt your data and then hold it for ransom, with the price being doing without security fixes in future kernels.
Quoted 9 lines
That last sentence is crap.
You're free to backport security fixes to cryptoloop-supporting kernels forever, or pay someone to do so. Or maintain a cryptoloop patch against current kernels, or pay someone to do so. Or write a converter for cryptoloop data to whatever's currently in the kernel, or pay someone to do so.
Given that CL has minimal (essentially no) maintenence cost, I wish
Quoted 13 lines
Quoted 7 lines
the ivory tower developers could understand that real people have invested real money in it, and real data in the technology. Since there is no alternative solution offered, CL is far better than no crypto at all, and I wish there were a few more developers who had experience working in the real word.
If you include a crypto solution in the mainstream kernel, you're in some sense endorsing its security. If that solution has known weaknesses, I can understand wanting to either fix it or rip it out. Crypto is hard enough to get right as it is.
Quoted 8 lines
Your "ivory tower" statement is really condescending. Linux is way past the stage where college students were the main contributors (if it ever was so after Linus graduated). and a great majority of developers now are paid to work on the kernel. There are probably very few of them that don't have at least a little sysadmin experience.
I wonder... running servers is relatively easy, supporting end user systems (admin, not help desk) is hard.
Quoted 5 lines
If you've invested money and put important data in a system, and you haven't contracted with anyone to support that system, supply security fixes, and make sure it does what you want it to do, who's the fool?
The advantage of using dynamic systems rather than locking in with something like RHEL was attractive. Trusting a third party was not.
Quoted 5 lines
Basically, you're complaining about something you get *for free* that represents millions of hours of work, because it doesn't work quite the way you want it to, when you have perfect freedom to make it meet your needs by putting in your own time, effort and/or money.
Most users have no such ability, but people jumped abord Linux when 2.6.0 came out, and it WAS called a "new stable release." Redefining what stable means after people have used the software is not something I would feel comfortable doing.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 1 line · Bill Davidsen
Given that CL has minimal (essentially no) maintenence cost,
then by your own admission maintaining it as an external patch for people who need it for legacy reasons is trivial, and removing it to discourage new users from picking it up remains a good idea.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lee RevellQuoted 13 lines · Lee Revell
Quoted 11 lines · Mark Lord
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Ah.. another one, that I was just reminded of again by the umpteenth person posting that their wireless no longer is WPA capable after upgrading from 2.6.12.
Of course, the known solution for that issue is to upgrade to the recently "fixed" latest
wpa_supplicantdaemon in userspace, since the old one no longer works.
Quoted 6 lines
Quoted 1 line
Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new
wpa_supplicantpackage. Don't they bother to test this stuff before they ship it?!?
Could you provide a little detail on the technology by which a distro checks for functionality against a kernel which wasn't necessarily released when the distro shipped. My udev doesn't generate /dev/timewarp.
Going to a new kernel in the same series shouldn't have to be treated as if it were a change to a whole new operating system, and shouldn't require completely replacing existing utilities with new ones which aren't backware compatible to allow fallback to the original kernel.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lee RevellQuoted 13 lines · Lee Revell
Quoted 11 lines · Mark Lord
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Ah.. another one, that I was just reminded of again by the umpteenth person posting that their wireless no longer is WPA capable after upgrading from 2.6.12.
Of course, the known solution for that issue is to upgrade to the recently "fixed" latest
wpa_supplicantdaemon in userspace, since the old one no longer works.
Quoted 6 lines
Quoted 1 line
Things like this are all too regular an occurance.
The distro should have solved this problem by making sure that the kernel upgrade depends on a new
wpa_supplicantpackage. Don't they bother to test this stuff before they ship it?!?
Could you provide a little detail on the technology by which a distro checks for functionality against a kernel which wasn't necessarily released when the distro shipped. My udev doesn't generate /dev/timewarp.
Going to a new kernel in the same series shouldn't have to be treated as if it were a change to a whole new operating system, and shouldn't require completely replacing existing utilities with new ones which aren't backware compatible to allow fallback to the original kernel.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Rob LandleyQuoted 16 lines · Rob Landley
Quoted 6 lines · Adrian Bunk
Quoted 5 lines · David Ranson
Quoted 3 lines · Steven Rostedt
udev ;)
Quoted 8 lines
Quoted 2 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
- support for ipfwadm and ipchains was removed during 2.6
- devfs support was removed during 2.6
- removal of kernel support for pcmcia-cs is pending
- ip{,6}_queue removal is pending
- removal of the RAW driver is pending
Quoted 4 lines
So what you're upset about is the feature removal scheduling mechanism, which usually gives a full year's warning, and the removal patch can be reversed into a feature addition patch you can maintain outside the tree if you really care?
I'm not upset about is the feature removal scheduling mechanism.
Please check who has most entries inDocumentation/feature-removal-schedule.txt ...
The removal of features within the 2.6 series is an essential part of the current development model.
The problem is the lack of a long-living relatively stable series within the development model.
Quoted 1 line
Rob
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to David RansonQuoted 3 lines · David Ranson
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
vbetool.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Mark Lord
Quoted 3 lines · David Ranson
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
vbetool.
I don't think vbetool has been "broken", it should work fine again. It was just temporarily (and unintentionally) broken for a while.
But if it's still broken in 2.6.15-rc4, please do holler (with as many details as you can)
Linus
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines · Linus Torvalds
I don't think vbetool has been "broken", it should work fine again. It was just temporarily (and unintentionally) broken for a while.
But if it's still broken in 2.6.15-rc4, please do holler
Yup, working fine again now with rc4.
Thanks Linus!
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to David RansonQuoted 9 lines · David Ranson
Quoted 5 lines · Steven Rostedt
udev ;)
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Not only that, udev is default for instance in recent SUSE Linux releases, so whether to use or not to use it is a major effort.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Matthias Andree
Quoted 4 lines · David Ranson
Quoted 2 lines · Steven Rostedt
udev ;)
Quoted 8 lines
Quoted 5 lines
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Not only that, udev is default for instance in recent SUSE Linux releases, so whether to use or not to use it is a major effort.
And if you use SUSE releases, use OpenSuSE to keep up to date with all of the needed kernel programs for the latest kernels. Same with Fedora, Debian, or Gentoo. They all keep up to date quite well.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Greg KH
And if you use SUSE releases, use OpenSuSE to keep up to date with all of the needed kernel programs for the latest kernels. Same with Fedora, Debian, or Gentoo. They all keep up to date quite well.
Well, particular problem I've had: netfilter-enabled machines were incapable to download large files, for instance newer ICC8 releases, (major annoyance, their IIS crap doesn't support "Bytes" ranges, so you start all over if one packet went down the wrong throat). I was told "try newer kernels first", there had been fixes with out-of-window ACKs and whatnot. I do not intend to upgrade all of my distro to the bleeding OpenSUSE release just to find out if the new kernel fixes it and to see new regressions. I have more interesting things to do with my time than chase the userspace change of the day.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Greg KHQuoted 13 lines · Greg KH
Quoted 12 lines · Matthias Andree
Quoted 9 lines · David Ranson
Quoted 5 lines · Steven Rostedt
udev ;)
Ahh OK .. I don't use it, so wouldn't have been affected. That's one userspace interface broken during the series, does anyone have any more?
Quoted 6 lines
Quoted 2 lines
Not only that, udev is default for instance in recent SUSE Linux releases, so whether to use or not to use it is a major effort.
And if you use SUSE releases, use OpenSuSE to keep up to date with all of the needed kernel programs for the latest kernels. Same with Fedora, Debian, or Gentoo. They all keep up to date quite well.
And if you use Debian, make sure you remember to do an update after changing a kernel and finding out that something in userland doesn't work. As Greg mentioned to me in the above mentioned thread. Debian/unstable had the proper udev. I just haven't done an update recently, but I download kernels practically every day.
-- Steve
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 4 lines
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
in kernel API never was and never will be stable, that's entirely irrelevant and independent of the proposal at hand.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Hi everyone.
Here to expose my point of view, hope u'll enjoy :)
Starting stable series off the 2.6 simply wouldn't work: there are no paid QA guys ready to test, fix, stabilize those series, kernel developers wants to hang on new exciting stuff.
This tendence leads to faster innovations in kernel core and features set but leaving the "forking" effort to distributions leads to fragmentation too: almost every distro has a different base kernel on which doing testing and fixing and this, in my opinion, is not positive for the kernel.org kernels. Another problem of the current development model is that fast changes are difficult to track for small external projects (those whitout big $$ behind), the small projects which made linux so great in the past.
Maybe a way to reduce those problems is to release the kernel like GNOME, KDE, fedora & co. do for their stuff: one stable release every 6 months but build on top of the current way of doing things. Example:
2.6.14 released on 27 October, then:
2.6.14.1-gitN until 2.6.14.1-rcN -> 2.6.14.1 2.6.14.2-gitN until 2.6.14.2-rcN -> 2.6.14.2
...
(maybe last 2.6.14-N, which could be called 2.6.15-gitN ->
2.6.15-rcN, only bugfixes and small changes, main development in -mm or in a new -something tree during this last phase) 2.6.15 release on March
those middle releases would be handled with the current development model except for the last one. So, the largest part of developers would continue to think and to work using the current development model and some guys would be able to plan a list of features and functionalities every 6 months and, based on this list, handle the 6-months release giving guide lines (like Linus and friends already do but, i repeat, focusing on a 6 months time window)
Doing things this way would lead to distributions aligning to the same kernel and open up a possible scenario of distros collaborating to mantain the latest stable release. This should make small projects and users who want to run bleeding edge stuff lifes easier too.
of couse the time window could be larger or smaller but doing things 6months-based should align kernel development to some other big projects too.
cheers,
Michele
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Arjan van de VenQuoted 7 lines · Arjan van de Ven
Quoted 4 lines
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
in kernel API never was and never will be stable, that's entirely irrelevant and independent of the proposal at hand.
It's still an annoying side effect - is there a list of kernel functions removed, with version removed, and with replacement? I know of none, but then again I don't hack the kernel very often.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Matthias Andree
Quoted 5 lines · Arjan van de Ven
Quoted 4 lines
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
Quoted 6 lines
Quoted 2 lines
in kernel API never was and never will be stable, that's entirely irrelevant and independent of the proposal at hand.
It's still an annoying side effect - is there a list of kernel functions removed, with version removed, and with replacement? I know of none, but then again I don't hack the kernel very often.
Both lwn.net and the kernelnewbies wiki are trying to track this.
thanks,
greg k-h
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 9 lines · Matthias Andree
Quoted 5 lines · Arjan van de Ven
Quoted 5 lines
Exactly that, and kernel interfaces going away just to annoy binary module providers also hurts third-party OSS modules, such as Fujitsu-Siemens's ServerView agents.
Quoted 11 lines
Quoted 4 lines
in kernel API never was and never will be stable, that's entirely irrelevant and independent of the proposal at hand.
It's still an annoying side effect - is there a list of kernel functions removed, with version removed, and with replacement? I know of none, but then again I don't hack the kernel very often.
These folks have nothing new to innovate here. The memory manager and VM gets revamped every other release. Exports get broken, binary only module compatibility busted every rev of the kernel. I spend weeks on each kernel fixing the breakage. These people don't get it, don't care, and to be honest, you are wasting your time here trying to convince them. It's never stable because they don't want it to be. This is how they maintain control of this code. I have apps written for Windows in 1990 and 1998 that still run on Windows XP today. Linux has no such concept of
backwards compatiblity. Every company who has embraced it outside of hardware based solutions is dying or has died. IBM is secretly
forking it as we speak and using it to get out of paying for Unix licenses.
As annoying as it is, accept it and live with it. These people have no sense of loyalty to you or your customers. They don't even care about each other. Linux is not a "family" in any sense. I wanted very much to believe this and I was loyal to these folks for 10 years, invested millions of dollars in development of my and others money in development to support it, crippled Novell and pushed them to embrace Linux and my reward was smearing and expulsion from the community. They have no direction and the whole thing is stagnant now. All the development is incremental bug fixes and anti-competitive mods to break each others distros.
You are standing on a battlefield. Quietly fork each release, make your mods, post patches somewhere for the poor civilians who are "collateral damage" in the war with constantly busted software, and you might help some folks.
Jeff
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Jeff V. Merkey
These folks have nothing new to innovate here. The memory manager and VM gets revamped every other release. Exports get broken, binary only module compatibility busted every rev of the kernel. I spend weeks on
Who cares for binary modules?
It hurts however if external OSS modules are broken.
Quoted 2 lines
of this code. I have apps written for Windows in 1990 and 1998 that still run on Windows XP today.
Sure, you're loading Windows 3.1 drivers into XP... You can tell us more of that crap later, but not here.
Properly written 1995 software usually still works on Linux as long as it doesn't need to care about kernel or devices.
[rest of Merkey rantings removed]
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Matthias Andree
Quoted 3 lines · Jeff V. Merkey
These folks have nothing new to innovate here. The memory manager and VM gets revamped every other release. Exports get broken, binary only module compatibility busted every rev of the kernel. I spend weeks on
Who cares for binary modules?
It hurts however if external OSS modules are broken.
then those modules should be submitted realistically. That's just best for everyone involved. Which modules in particular do you mean btw?
It's rare even in the 2.6 tree to mass-break well written drivers. Just because it's a lot of work to fix all in kernel drivers up. But a fully stable API is also not good. My guess is that the drivers that break most are the ones using the not-right APIs (eg internals and such).
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Arjan van de Ven
Quoted 6 lines · Matthias Andree
Quoted 3 lines · Jeff V. Merkey
These folks have nothing new to innovate here. The memory manager and VM gets revamped every other release. Exports get broken, binary only module compatibility busted every rev of the kernel. I spend weeks on
Quoted 6 lines
Quoted 3 lines
Who cares for binary modules?
It hurts however if external OSS modules are broken.
then those modules should be submitted realistically. That's just best for everyone involved. Which modules in particular do you mean btw?
I meant the ipmi, smbus and copa modules by Fujitsu-Siemens.
They are provided in source form, but I just found out (reading the headers and not just the lines that broke the compile) they are not open source. Perhaps one should prod them to slap a modified-BSD or perhaps GPL label onto their modules.
It seems you'd then maintain them after their submission? :-)
Quoted 4 lines
It's rare even in the 2.6 tree to mass-break well written drivers. Just because it's a lot of work to fix all in kernel drivers up. But a fully stable API is also not good. My guess is that the drivers that break most are the ones using the not-right APIs (eg internals and such).
These use inter_module_get() (ok, inter_module_get_request isn't difficult) and some #include headers that have moved around between linux and asm directories.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Matthias Andree
I meant the ipmi, smbus and copa modules by Fujitsu-Siemens.
They are provided in source form, but I just found out (reading the headers and not just the lines that broke the compile) they are not open source. Perhaps one should prod them to slap a modified-BSD or perhaps GPL label onto their modules.
is there an URL to these?
Quoted 2 lines
It seems you'd then maintain them after their submission? :-)
usually such modules are extremely low maintenance once merged.... There are many many drivers without a maintainer, and they still get fixed.
Quoted 6 lines
Quoted 4 lines
It's rare even in the 2.6 tree to mass-break well written drivers. Just because it's a lot of work to fix all in kernel drivers up. But a fully stable API is also not good. My guess is that the drivers that break most are the ones using the not-right APIs (eg internals and such).
These use
inter_module_get()
which is still there even in the latest 2.6.15-rc. It should be going out but hasn't yet. And that is the case for at least a year (eg they are __deprecated but still there).
Quoted 2 lines
and some #include headers that have moved around between
linux and asm directories.
Most of those were already in the final place with a temporary compat header in the old one I guess. But if this is all.... that really isn't a big deal. I suspect some of these headers aren't even used by the driver (sometimes people just include the world for no reason)..
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Arjan van de Ven
Quoted 6 lines · Matthias Andree
I meant the ipmi, smbus and copa modules by Fujitsu-Siemens.
They are provided in source form, but I just found out (reading the headers and not just the lines that broke the compile) they are not open source. Perhaps one should prod them to slap a modified-BSD or perhaps GPL label onto their modules.
is there an URL to these?
Quoted 4 lines
Quoted 1 line
It seems you'd then maintain them after their submission? :-)
usually such modules are extremely low maintenance once merged.... There are many many drivers without a maintainer, and they still get fixed.
As I say, these aren't licensed for inclusion into the kernel, they bear a (C) Copyright notice and "All rights reserved."
Quoted 5 lines
Quoted 1 line
These use
inter_module_get()which is still there even in the latest 2.6.15-rc. It should be going out but hasn't yet. And that is the case for at least a year (eg they are
__deprecatedbut still there).
No, they aren't - at least not anywhere declared below include/ and thus uncompilable with GCC4.
Quoted 4 lines
Most of those were already in the final place with a temporary compat header in the old one I guess. But if this is all.... that really isn't a big deal. I suspect some of these headers aren't even used by the driver (sometimes people just include the world for no reason)..
The reason would be convenience, or maintainer efficiency as the Camel book ("Programming Perl") words it.
If not including the right header file (such as ioctl32.h on x86_64) breaks the compile, I presume they are needed.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 15 lines · Matthias Andree
Quoted 10 lines · Arjan van de Ven
Quoted 6 lines · Matthias Andree
I meant the ipmi, smbus and copa modules by Fujitsu-Siemens.
They are provided in source form, but I just found out (reading the headers and not just the lines that broke the compile) they are not open source. Perhaps one should prod them to slap a modified-BSD or perhaps GPL label onto their modules.
is there an URL to these?
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
It seems you'd then maintain them after their submission? :-)
usually such modules are extremely low maintenance once merged.... There are many many drivers without a maintainer, and they still get fixed.
As I say, these aren't licensed for inclusion into the kernel, they bear a (C) Copyright notice and "All rights reserved."
andMODULE_LICENSE("GPL");
so it *IS* gpl licensed!
the code is a bit horrible though and no surprise it breaks ;)
you can always make drivers broken enough to break at the slightest change ;)
(it also seems to contain an entire ipmi layer, linux already has one so I wonder why they're not just using that as basis)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Arjan van de Ven
Quoted 2 lines
As I say, these aren't licensed for inclusion into the kernel, they bear a (C) Copyright notice and "All rights reserved."
and
MODULE_LICENSE("GPL");so it *IS* gpl licensed!
the code is a bit horrible though and no surprise it breaks ;)
Yes. "extern type foo; static type foo;" is way stupid, but 10% of the blame can be shifted on the GCC guys for being much too tolerant.
Quoted 5 lines
you can always make drivers broken enough to break at the slightest change ;)
(it also seems to contain an entire ipmi layer, linux already has one so I wonder why they're not just using that as basis)
Perhaps the dates give a clue. Since when has Linux had IPMI in the baseline code?
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines
Perhaps the dates give a clue. Since when has Linux had IPMI in the baseline code?
2.4.21 already had it, so it's been quite a while
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 2 lines · Matthias Andree
Yes. "extern type foo; static type foo;" is way stupid, but 10% of the blame can be shifted on the GCC guys for being much too tolerant.
You should rather blame the C standard.
Andreas.
Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Andreas Schwab
Quoted 2 lines · Matthias Andree
Yes. "extern type foo; static type foo;" is way stupid, but 10% of the blame can be shifted on the GCC guys for being much too tolerant.
You should rather blame the C standard.
There are things that old Sun Workshop versions bitch about that GCC deals with without complaining, and I'm not talking about C99/C++-style comments. C standard issue? I believe not.
Anyways, this is getting off-topic and ultimately the author of broken code is responsible, of course. But it's still nice if the tools help produce good code.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Matthias Andree
There are things that old Sun Workshop versions bitch about that GCC deals with without complaining, and I'm not talking about C99/C++-style comments. C standard issue? I believe not.
I have seen many a code like so:
char buf[4];
memcpy(buf, source, 5);accepted by the Sun compilers and run just fine. When the application was ported to Linux/GCC, the developers complained their program segfaulted, and "it must be something broken on Linux!"
Just because Sun's compiler does something doesn't mean it's
right :-)
Joel
Signature · 9 lines
Life's Little Instruction Book #510 "Count your blessings." Joel Becker Principal Software Developer Oracle E-mail: [email protected] Phone: (650) 506-8127
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Joel Becker
Quoted 3 lines · Matthias Andree
There are things that old Sun Workshop versions bitch about that GCC deals with without complaining, and I'm not talking about C99/C++-style comments. C standard issue? I believe not.
I have seen many a code like so: char buf[4]; memcpy(buf, source, 5);
Quoted 4 lines
accepted by the Sun compilers and run just fine. When the application was ported to Linux/GCC, the developers complained their program segfaulted, and "it must be something broken on Linux!"
Just because Sun's compiler does something doesn't mean it's
It isnt the compiler quite often. The usual case is
char buf[4]; strcpy(buf, "bits");
And those cases usually work because its a big endian box and the \00 ends up overwriting the \00 in the return address.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 4 lines · Matthias Andree
As I say, these aren't licensed for inclusion into the kernel, they bear a (C) Copyright notice and "All rights reserved."
In the 2.6.15-rc5 kernel we find:
data@amazon linux-2.6.15-rc5]$ find . -name *.[chS] | xargs grep -n "All rights reserved" | wc -l 932
[data@amazon linux-2.6.15-rc5]$ find . -name *.[chS] | xargs grep -n "Copyright" | wc -l 15083
But I do wonder how copyright and GPL can co-exist. Do the copyright holder own the changes anybody else does to the code? Anyone care to explain?
Thanks
Richard Knutsson
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 4 lines
But I do wonder how copyright and GPL can co-exist. Do the copyright holder own the changes anybody else does to the code? Anyone care to explain?
The GPL *is* copyright. You and I as copyright holders reserve all rights, and then grant selected rights; the rights and the conditions they are granted under are described in the COPYING file. It's a misunderstanding to think that GPL means "no copyright" or "can do anything I want"; in a way the GPL is quite a restrictive license. (while it allows you to distribute, copy and make derived works, it only does allow that under the condition that the result is made available under the GPL as well in full source form, and there's some additional conditions as well)
so GPL can copyright are not in conflict, the GPL can exist BECAUSE of copyright actually.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Richard KnutssonQuoted 3 lines · Richard Knutsson
But I do wonder how copyright and GPL can co-exist. Do the copyright holder own the changes anybody else does to the code? Anyone care to explain?
The GPL is a copyright license. A license is a permission statement, ala "you can pitch a tent on my lawn as long as you don't leave trash all over it". Doesn't change ownership of the lawn, just says what you can do with the lawn somebody else owns, and it can have strings attached.
Quoted 2 lines
Thanks
Richard Knutsson
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Richard KnutssonQuoted 2 lines · Richard Knutsson
But I do wonder how copyright and GPL can co-exist. Do the copyright holder own the changes anybody else does to the code? Anyone care to explain?
IANAL, but GPL is a copyright license. Copyright is the right to make copies of somethings, to distribute it to be precise.
So if I write foo.c and release it under the GPL, and JR Hacker takes it and writes foo++.c but doesn't give his super duper sekrit version to anyone, then he isn't bound by copyright laws (he isn't making copies) and therefore the GPL doesn't hold for him.
The moment he wants to give a copy to his best friend, the GPL does kick in, though, and he has to abide by the GPL and distribute the whole piece (as it is a "derivative work") with the source code included (or an offer, or whatever. Read the GPL sometime, its not legalese at all).
For more information, ask your friendly (*cough*) neighborhood lawyer.
Signature · 5 lines
[Name ] :: [Matan I. Peled ] [Location ] :: [Israel ] [Public Key] :: [0xD6F42CA5 ] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 10 lines
(C) Copyright notice and "All rights reserved."
Quoted 5 lines
Quoted 1 line
These use
inter_module_get()which is still there even in the latest 2.6.15-rc. It should be going out but hasn't yet. And that is the case for at least a year (eg they are
__deprecatedbut still there).No, they aren't - at least not anywhere declared below
include/and thus uncompilable with GCC4.
# pwd /mnt/raid/linux/linux-2.6.15-rc4/include/linux [root@jackhammer linux]# grep inter_mod * module.h:extern void __deprecated inter_module_register(const char *, module.h:extern void __deprecated inter_module_unregister(const char *); module.h:extern const void * __deprecated inter_module_get_request(const char *, module.h:extern void __deprecated inter_module_put(const char *);
sounds you need to invoke the warranty on your grep binary ;)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Arjan van de Ven
Quoted 10 lines
(C) Copyright notice and "All rights reserved."
Quoted 5 lines
Quoted 1 line
These use
inter_module_get()which is still there even in the latest 2.6.15-rc. It should be going out but hasn't yet. And that is the case for at least a year (eg they are
__deprecatedbut still there).No, they aren't - at least not anywhere declared below
include/and thus uncompilable with GCC4.
Quoted 8 lines
# pwd /mnt/raid/linux/linux-2.6.15-rc4/include/linux [root@jackhammer linux]# grep inter_mod * module.h:extern void __deprecated inter_module_register(const char *, module.h:extern void __deprecated inter_module_unregister(const char *); module.h:extern const void * __deprecated inter_module_get_request(const char *, module.h:extern void __deprecated inter_module_put(const char *);
Same story with -rc5. As you can see, there is no declaration for inter_module_get(), just the _request() variant. So what now? :-P
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Jeff V. MerkeyQuoted 2 lines · Jeff V. Merkey
Quoted 1 line · Matthias Andree
On Sat, 03 Dec 2005, Arjan van de Ven wrote:
[...]
Quoted 2 lines
These folks have nothing new to innovate here. The memory manager and VM gets revamped every other release.
That is a sign of movement. Sure, one can argue if it is random movement of definite progress, but change /is/ a part of innovation.
Quoted 2 lines
Exports get broken, binary only
module compatibility busted every rev of the kernel.
In-kernel API was /never/ guaranteed, so you have nothing to complain here.
Quoted 2 lines
I spend weeks on
each kernel fixing the breakage. These people don't get it,
They do get it, and have their reasons to act this way. Reasons you don't get, it seems.
Quoted 1 line
don't care,
They do care. But not about the same thing you care about.
Quoted 2 lines
and to be honest, you are wasting your time here trying to convince them.
It is /their/ code, with which they are free to do as they wish. If you contribute enough, you get a say in it too; until that time, just be grateful for what you get given freely.
Quoted 2 lines
It's never stable because they don't want it to be. This is how
they maintain control of this code.
Licensing under GPL while "maintaining control" is a contradiction in terms. If you don't like where the development is going, you are free to fork it. Just the developers won't follow you, as the consensus between them is against your wishes.
Quoted 2 lines
I have apps written for Windows in
1990 and 1998 that still run on Windows XP today.
I have programs written in the early 80s that still can be compiled and run on Linux. And AFAIK the very first a.out binaries for Linux still work (I'd assume that setting up the shared libraries for them is a royal pain).
I have programs by /Microsoft/ which don't run after Win98, even though they are supposed to run on later versions.
Besides, this backward compatibility is exactly one of the major reasons for Windows breakage, they just can't get a clean cut from the past.
Quoted 2 lines
Linux has no such
concept of backwards compatiblity.
For user programs? Sure is.
Quoted 2 lines
Every company who has embraced it
outside of hardware based solutions is dying or has died.
So?
Quoted 3 lines
IBM is secretly
forking it as we speak and using it to get out of paying for Unix licenses.
Could you please give some kind of evidence for this misbehaviour by IBM?
Quoted 3 lines
As annoying as it is, accept it and live with it. These people have no sense of loyalty to you or your customers. They don't even care about each other.
Right. Their only loyalty is to a better kernel (system). Nothing else. Nobody /ever/ promised anything else, in fact, they have /always/ stated that that is their only objective. You definitely haven't gotten shafted.
[...]
Quoted 4 lines
You are standing on a battlefield. Quietly fork each release, make your mods, post patches somewhere for the poor civilians who are "collateral damage" in the war with constantly busted software, and you might help some folks.
This is what distributions do routinely... and the current development model is precisely to /disminish/ the cost of keeping up to date by third parties. In that sense the kernel community /does/ care for them, just that they don't make any promises. Take it or leave it. There are alternatives, like the various BSD flavors. Or even Solaris, or closed Unix variants.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Jeff V. MerkeyOn Sat, 2005-12-03 at 17:52 -0700, Jeff V. Merkey wrote:
[...]
Quoted 1 line
of this code. I have apps written for Windows in 1990 and 1998 that
^^^^
Quoted 1 line
still run on Windows XP today. Linux has no such concept of
But this not even holds for nearly all apps.
Quoted 1 line
backwards compatiblity. Every company who has embraced it outside of
The same holds (probably) for Linux apps (given that your kernel can start a.out). And AFAIBT by Win* driver developers even in the Win* world you have to change your driver because of a new Win* version now and then.
Bernd
Signature · 3 lines
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and ServicesRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 22 lines · Bernd Petrovitsch
On Sat, 2005-12-03 at 17:52 -0700, Jeff V. Merkey wrote:
[...]Quoted 3 lines
of this code. I have apps written for Windows in 1990 and 1998 that
^^^^Quoted 3 lines
still run on Windows XP today. Linux has no such concept of
But this not even holds for nearly all apps.
Quoted 3 lines
backwards compatiblity. Every company who has embraced it outside of
Quoted 8 lines
The same holds (probably) for Linux apps (given that your kernel can start a.out). And AFAIBT by Win* driver developers even in the Win* world you have to change your driver because of a new Win* version now and then.
Bernd
No. BIND was has been busted between 2.4 and 2.6. Not to mention the whole libc -> glib switchover. It's hilarious that BSD had to create a Linux app compat lib, and the RedHat shipped compat libs for 3 releases
as well. Not even close. Windows has won. M$ has won. Linux lost the desktop wars and will soon loose
the server wars as well. The reason - infighting and lack of backwards compatibility. Binary only module
breakage kernel to kernel will continue.
Jeff
Re: RFC: Starting a stable kernel series off the 2.6 kernel
[ Minimized quoted part ]
Quoted 2 lines · Jeff V. Merkey
Quoted 1 line · Bernd Petrovitsch
On Sat, 2005-12-03 at 17:52 -0700, Jeff V. Merkey wrote:
[...]
Quoted 12 lines
Quoted 12 lines
Quoted 1 line
of this code. I have apps written for Windows in 1990 and 1998 that
^^^^Quoted 1 line
still run on Windows XP today. Linux has no such concept of
But this not even holds for nearly all apps.
Quoted 1 line
backwards compatiblity. Every company who has embraced it outside of
The same holds (probably) for Linux apps (given that your kernel can start a.out). And AFAIBT by Win* driver developers even in the Win* world you have to change your driver because of a new Win* version now and then.
[...]
Quoted 1 line
No. BIND was has been busted between 2.4 and 2.6. Not to mention the
Hmmm, URL? Details? I can't remember anything about such issues.
Quoted 1 line
whole libc -> glib switchover.
glib has AFAIK next to nothing to do with a libc AFAICT (i.e. it is using standard libc functions but that's all).
Quoted 2 lines
It's hilarious that BSD had to create a Linux app compat lib, and the RedHat shipped compat libs for 3 releases
Here you have your backwards compatibility.
Quoted 3 lines
as well. Not even close. Windows has won. M$ has won. Linux lost
the desktop wars and will soon loose
the server wars as well. The reason - infighting and lack of backwards
Yes, probably - MSFT is spreading the same story since ages.
Quoted 2 lines
compatibility. Binary only module
breakage kernel to kernel will continue.
As other told there never was a stable kernel module interface. Of course there is probably enough willing manpower out there who will work on that once you pay them. Or you can provide such support on your own.
Or do you (or anybody else) has drivers which should be maintained for vanilla-kernel and/or vendor kernels and/or other kernels (to fix the breakage in a cosntructive way), we can provide you with an offer to do that.
Bernd
Signature · 3 lines
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and ServicesRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 17 lines · Bernd Petrovitsch
[ Minimized quoted part ]
Quoted 2 lines · Jeff V. Merkey
Quoted 1 line · Bernd Petrovitsch
On Sat, 2005-12-03 at 17:52 -0700, Jeff V. Merkey wrote:
[...]
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
of this code. I have apps written for Windows in 1990 and 1998 that
^^^^Quoted 1 line
still run on Windows XP today. Linux has no such concept of
Quoted 8 lines
Quoted 8 lines
But this not even holds for nearly all apps.
Quoted 1 line
backwards compatiblity. Every company who has embraced it outside of
The same holds (probably) for Linux apps (given that your kernel can start a.out). And AFAIBT by Win* driver developers even in the Win* world you have to change your driver because of a new Win* version now and then.
Quoted 5 lines
[...]
Quoted 1 line
whole libc -> glib switchover.
glib has AFAIK next to nothing to do with a libc AFAICT (i.e. it is using standard libc functions but that's all).
He refers to the a.out to ELF switchover. Yes, it was painful. But not as much as he makes out. The Win98 --> WinNT change was worse, IMHO.
Quoted 1 line
Quoted 1 line
It's hilarious that BSD had to create a Linux app compat lib,
And Solaris forever had a BSD compatibility suite, including libraries and tools. So what?
Quoted 2 lines
Quoted 2 lines
and the
RedHat shipped compat libs for 3 releases
So legacy stuff continued working. And that is bad how?
Quoted 1 line
Here you have your backwards compatibility.
Right.
Quoted 2 lines
Quoted 2 lines
as well. Not even close. Windows has won. M$ has won. Linux lost
the desktop wars
First of all, Linux isn't about "winning a war". And the desktop wars haven't really started...
Quoted 1 line
Quoted 1 line
and will soon loose the server wars as well.
Sorry, but that one is almost over, and Linux has won.
Quoted 4 lines
Quoted 2 lines
The
reason - infighting and lack of backwardsYes, probably - MSFT is spreading the same story since ages.
Gandhi-con 3 ;-)
Quoted 2 lines
Quoted 2 lines
compatibility. Binary only
module breakage kernel to kernel will continue.
So what? Binary modules are mostly bad and break the kernel, so...
Quoted 3 lines
As other told there never was a stable kernel module interface. Of course there is probably enough willing manpower out there who will work on that once you pay them. Or you can provide such support on your own.
Right.
Quoted 4 lines
Or do you (or anybody else) has drivers which should be maintained for vanilla-kernel and/or vendor kernels and/or other kernels (to fix the breakage in a cosntructive way), we can provide you with an offer to do that.
Constructive criticism? Even of the sort that contributes something? What are you thinking about?!
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 1 line · Horst von Brand
Bernd Petrovitsch <[email protected]> wrote:
[...]
[...]
Quoted 1 line
Quoted 1 line
Quoted 1 line
whole libc -> glib switchover.
Ah, that should have read "libc.5(*) to glibc" switchover"? (*) IIRC.
Quoted 4 lines
Quoted 2 lines
glib has AFAIK next to nothing to do with a libc AFAICT (i.e. it is using standard libc functions but that's all).
He refers to the a.out to ELF switchover. Yes, it was painful. But not as
Was it? And it was ages ago (i can't even remember since when I disable a.out in the kernel completely and never had a problem with it).
Quoted 1 line
much as he makes out. The Win98 --> WinNT change was worse, IMHO.
Of course. Especially if you started to use the permission system and not let the NT installation stay in the default mode where every user may do everything everywhere (and they are hiding the contents of certain directories in the file browser instead of simply letting the administrator change it's contents so that folks really learn it).
[....]
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
The
reason - infighting and lack of backwardsYes, probably - MSFT is spreading the same story since ages.
Gandhi-con 3 ;-)
???? Sorry, what do you mean?
[...]
Quoted 4 lines
Quoted 3 lines
As other told there never was a stable kernel module interface. Of course there is probably enough willing manpower out there who will work on that once you pay them. Or you can provide such support on your own.
Quoted 8 lines
Right.
Quoted 4 lines
Or do you (or anybody else) has drivers which should be maintained for vanilla-kernel and/or vendor kernels and/or other kernels (to fix the breakage in a cosntructive way), we can provide you with an offer to do that.
Constructive criticism? Even of the sort that contributes something? What
No, since we interface here with the commercial world , it is a commercial offer (well, sort of - at least a an offer to provide an offer it the details and requirements are defined/clear).
Quoted 1 line
are you thinking about?!
$COMPANY wants a maintained "open" driver (probably GPL but that's not the point)?
$COMPANY gives us money (a to be defined amount of money for a to be defined time, for to be defined distributions and/or kernel trees, to be defined QA with respect to the hardware driven by the driver, etc.) and we do that for you.
Feel free to ignore it ....
Bernd
Signature · 3 lines
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and ServicesGolden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
In reply to Adrian BunkQuoted 3 lines · Adrian Bunk
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
Fix the real problem: publicly shame kernel hackers that change userland ABI/API without LOTS of notice, and hopefully an old-userland compatibility solution implemented.
We change kernel APIs all the time. Having made that policy decision, we have the freedom to rapidly improve the kernel, and avoid being stuck with poor designs of the past.
Userland isn't the same. IMO sysfs hackers have forgotten this. Anytime you change or remove sysfs attributes these days, you have the potential to break userland, which breaks one of the grand axioms of Linux. Everybody knows "the rules" when it comes to removing system calls, but forgets/ignores them when it comes to ioctls, sysfs attributes, and the like.
Thus, I've often felt that heavy sysfs (and procfs) use made it too easy to break userland. Maybe we should change the sysfs API to include some sort of interface versioning, or otherwise make it more obvious to the programmer that they could be breaking userland compat.
Offhand, once implemented and out in the field, I would say a userland interface should live at least 1-2 years after the "we are removing this interface" warning is given.
Yes, 1-2 years. Maybe even that is too small. We still have old_mmap syscall around :)
Jeff
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
Quoted 2 lines · Jeff Garzik
Userland isn't the same. IMO sysfs hackers have forgotten this.
No we have not.
Quoted 5 lines
Anytime you change or remove sysfs attributes these days, you have the potential to break userland, which breaks one of the grand axioms of Linux. Everybody knows "the rules" when it comes to removing system calls, but forgets/ignores them when it comes to ioctls, sysfs attributes, and the like.
The _main_ reason of making sysfs contain "one value per file" was to help mitigate the problems that proc has had in the past where file format changes broke userspace programs.
Programs that rely on sysfs need to be able to safely handle the fact that some attributes might or might not be there.
Now to be fair, yes, udev has had big problems with this in the past, and kernel updates have broken udev. But that was because the bug was MY fault in udev, not in the kernel. I'll take full responsibility for that.
And in the future, the driver/class model changes we are going to be doing (see http://lwn.net/Articles/162242/ for more details on this), will be going to great lengths to prevent anything in userspace from breaking.
So, to change your wording a bit, users of sysfs have forgotten how to program defensively to handle changes that might happen in the future. I know I'm guilty of this, and am working hard to not make the same mistakes in the future.
thanks,
greg "still trying to delete devfs after 1 and 1/2 years notice" k-h
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
Quoted 4 lines · Greg KH
And in the future, the driver/class model changes we are going to be doing (see http://lwn.net/Articles/162242/ for more details on this), will be going to great lengths to prevent anything in userspace from breaking.
It is usually considered a bad netiquette to cross-post in public and subscription-only lists. I wonder if pointing to subscription-only service to get the feeling about planned driver core changes is a good idea. I would expect it be stated here or on hotplug list but don't recall anything interesting in the last couple of weeks. Is there a driver core mailing list I need to subscribe?
Signature · 1 line
Dmitry
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
Quoted 10 lines · Dmitry Torokhov
Quoted 4 lines · Greg KH
And in the future, the driver/class model changes we are going to be doing (see http://lwn.net/Articles/162242/ for more details on this), will be going to great lengths to prevent anything in userspace from breaking.
It is usually considered a bad netiquette to cross-post in public and subscription-only lists. I wonder if pointing to subscription-only service to get the feeling about planned driver core changes is a good idea.
My apologies. It is merely a detailed description of what I wrote up here:
http://www.kroah.com/log/linux/driver_model_changes.html
I'll forward you a link to it off-list in a minute (and to anyone else who wants it.) After a week, lwn.net is free, so it will be public.
thanks,
greg k-h
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
Quoted 7 lines · Greg KH
Quoted 6 lines · Dmitry Torokhov
Quoted 4 lines · Greg KH
And in the future, the driver/class model changes we are going to be doing (see http://lwn.net/Articles/162242/ for more details on this), will be going to great lengths to prevent anything in userspace from breaking.
Quoted 9 lines
Quoted 4 lines
It is usually considered a bad netiquette to cross-post in public and subscription-only lists. I wonder if pointing to subscription-only service to get the feeling about planned driver core changes is a good idea.
My apologies. It is merely a detailed description of what I wrote up here:
http://www.kroah.com/log/linux/driver_model_changes.html
Ahh, I see.
Quoted 3 lines
I'll forward you a link to it off-list in a minute (and to anyone else who wants it.) After a week, lwn.net is free, so it will be public.
That is allright, the link above is all I needed. I don't really want to use LWN "ahead of time" - they sell subsciptions - good for them.
--
Dmitry
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
In reply to Jeff GarzikQuoted 6 lines
Userland isn't the same. IMO sysfs hackers have forgotten this. Anytime you change or remove sysfs attributes these days, you have the potential to break userland, which breaks one of the grand axioms of Linux. Everybody knows "the rules" when it comes to removing system calls, but forgets/ignores them when it comes to ioctls, sysfs attributes, and the like.
procfs needs to be mentioned in a main clause (rather than parenthesized and in a subordinate clause), too. I don't recall if breakage happened at 2.6.0 or some other time, this however is pretty annoying, as much as the need to use unstable and undocumented 0.X version kernel support libraries or daemons utilities.
One /proc example: The removal of /proc/scsi/$DRIVER/$CARD broke for instance the 3ware Escalade 6000/7000/8000 series 3DM tools - and the driver IS open source.
OK, in this case it doesn't hurt because the 9000 series 3DM2 tools work, but it takes a while to figure *that* out.
Quoted 6 lines
Offhand, once implemented and out in the field, I would say a userland interface should live at least 1-2 years after the "we are removing this interface" warning is given.
Yes, 1-2 years. Maybe even that is too small. We still have
old_mmapsyscall around :)
It should be "2 years or next kernel minor release, whatever comes later". I understand that to developers, keeping old gears and wheels around is an annoyance, but knowing one is in to support this for three years or so makes some people think twice about adding things or changing things in incompatible ways. And making people think twice can only improve quality.
Signature · 1 line
Matthias Andree
Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)
In reply to Jeff GarzikQuoted 18 lines · Jeff Garzik
Quoted 6 lines · Adrian Bunk
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
Fix the real problem: publicly shame kernel hackers that change userland ABI/API without LOTS of notice, and hopefully an old-userland compatibility solution implemented.
We change kernel APIs all the time. Having made that policy decision, we have the freedom to rapidly improve the kernel, and avoid being stuck with poor designs of the past.
Quoted 7 lines
Userland isn't the same. IMO sysfs hackers have forgotten this. Anytime you change or remove sysfs attributes these days, you have the potential to break userland, which breaks one of the grand axioms of Linux. Everybody knows "the rules" when it comes to removing system calls, but forgets/ignores them when it comes to ioctls, sysfs attributes, and the like.
WRT sysfs, sysfs is dynamic by design to accommodate individual HW configuration. Thus isn't this really a fault of user-space implementation?
Quoted 6 lines
Thus, I've often felt that heavy sysfs (and procfs) use made it too easy to break userland. Maybe we should change the sysfs API to include some sort of interface versioning, or otherwise make it more obvious to the programmer that they could be breaking userland compat.
You might need versions for every entry. I'd go for more documentation on proper use.
Quoted 11 lines
Offhand, once implemented and out in the field, I would say a userland interface should live at least 1-2 years after the "we are removing this interface" warning is given.
Yes, 1-2 years. Maybe even that is too small. We still have
old_mmapsyscall around :)Jeff
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 2 lines · Adrian Bunk
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
A) udev changing its interface every three months isn't the kernel's fault, it's udev's. Heck, udev doesn't even accept a dependency on an external libsys but instead bundles its own copy in there because obviously the proper way to use a shared library is to block copy it into the source tree of every potential user. Its config file format keeps changing. What commands you run to invoke it keeps changing. What does that have to do with the kernel?
Attached is a shell script that does the basics of what udev does. (No, it doesn't handle permissions or persistent naming. But it also doesn't show a lot of version dependencies, does it?)
B) When I install new packages I have to update dependencies like SDL or zlib all the time, yet you believe the kernel isn't allowed to have dependencies? Not even on things like modprobe or glibc that interface to the kernel not just graphically but "with tongue", as it were? (Despite that, they're pretty darn good at staying compatible anyway.)
Quoted 3 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
Oh don't start throwing around "must" and "officially announced" as if those terms actually mean something.
If you can come up with a compelling proposal and implement it and attract followers, fine. You don't need to grab a flag and get blessed by somebody else to do anything. (Whose flag and blessing did Linus get way back when? And where the heck did Ubuntu or Gentoo come from?)
The _right_ way to do this would have been to announce that you are maintaining a new tree, a -stable fork of whatever release, and give a URL to where it can be downloaded. Announce code, not intentions. (Announcing intentions never works. Code attracts code and talk attracts talk.) And that way the difficulty and sustainability of your task becomes self-apparent.
By the way, I'll guarantee you I can configure a 2.6.15 kernel that your userspace won't work with, with no code changes. (To start with, I'd yank elf and force you to use a.out executable format...)
Quoted 2 lines
For how many years do you think we will be able to ensure that this will stay true?
Who is "we", kemosabe?
Quoted 2 lines
cu
Adrian
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 12 lines · Adrian Bunk
Quoted 6 lines · Arjan van de Ven
If the current model doesn't work as you claim it doesn't, then maybe the model needs finetuning. Right now the biggest pain is the userland ABI changes that need new packages; sometimes (often) for no real hard reason. Maybe we should just stop doing those bits, they're not in any fundamental way blocking general progress (sure there's some code bloat due to it, but I guess we'll just have to live with that).
IOW, we should e.g. ensure that today's udev will still work flawlessly with kernel 2.6.30 (sic)?
Quoted 6 lines
This could work, but it should be officially announced that e.g. a userspace running kernel 2.6.15 must work flawlessly with _any_ future 2.6 kernel.
For how many years do you think we will be able to ensure that this will stay true?
I'd rather see the statement that if a kernel 2.6.N requires a userspace update (udev, alsa, whatever), that the new userspace works correctly on 2.6.(N-10).
I think that is the bit of the problem that has been really frustrating to the people that have run into it.
(I think that is the complaint Dave Jones made during his OLS keynote, and I've seen a similar complaint about udev, though the udev issue may have been Debian specific.)
Signature · 2 lines
Ryan Anderson sometimes Pug Majere
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 11 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)
Quoted 3 lines
One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
What you're suggesting sounds just like going back to the old style of development where 2.<even>.x is stable, and 2.<odd>.x is development. You might as well just suggest that after 2.6.16, we fork to 2.7.0, and 2.6.17+ will be stable increments like we always used to do.
You're just munging the version scheme :)
Signature · 3 lines
Ben Collins <[email protected]> Developer Ubuntu Linux
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 16 lines · Ben Collins
Quoted 11 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)Quoted 3 lines
One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
Quoted 6 lines
What you're suggesting sounds just like going back to the old style of development where 2.<even>.x is stable, and 2.<odd>.x is development. You might as well just suggest that after 2.6.16, we fork to 2.7.0, and 2.6.17+ will be stable increments like we always used to do.
You're just munging the version scheme :)
The 2.6.17+ development model is different from a traditional 2.7 development model in the sense that 2.6.17+ contains regular relatively stable releases.
But yes, what I suggest is partially a step back in a way that it doesn't conflict with the current 2.6.17+ development model.
Well, if taking the best from the old style development is improving things that isn't something bad.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Adrian Bunk
But yes, what I suggest is partially a step back in a way that it doesn't conflict with the current 2.6.17+ development model.
Well, if taking the best from the old style development is improving things that isn't something bad.
You seem to be saying that the current development model is unacceptable for users for whom older kernel work just fine, and the main risk in upgrading is regression. But the new development model is clearly needed for those users whose needs are not met by the old kernel, say due to unacceptable soft RT performance or unsupported hardware.
But it's wrong to try to evenly balance the needs of these two classes of users, because the first class has another option - they can stick with the old kernel that works for them. The second class of users has no other option, so their needs should be given greater weight.
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 19 lines · Lee Revell
Quoted 6 lines · Adrian Bunk
But yes, what I suggest is partially a step back in a way that it doesn't conflict with the current 2.6.17+ development model.
Well, if taking the best from the old style development is improving things that isn't something bad.
You seem to be saying that the current development model is unacceptable for users for whom older kernel work just fine, and the main risk in upgrading is regression. But the new development model is clearly needed for those users whose needs are not met by the old kernel, say due to unacceptable soft RT performance or unsupported hardware.
But it's wrong to try to evenly balance the needs of these two classes of users, because the first class has another option - they can stick with the old kernel that works for them. The second class of users has no other option, so their needs should be given greater weight.
Quoted 8 lines
Lee
-
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/
Mhhh something much simpler:
Use the current development model between 2.6.N and 2.6.N+1. This means the current dev model would be used like NOW, BUT changing the versioning scheme in a way which reflects the 6months release plans. TRYING TO EXPLAIN THINGS BETTER: You could skip the version scheme change and do something like:
EXAMPLE:
2.6.14 - ok let's plan 3/4/whatever releases in the next 6 months with those major new features:
- A
- B
- C
then: .15, .16 like every 2.6 kernel, same dev model, same everything (erhm not every just like the latest releases, ok)
.18 would be MAINLY stabilization: no device model changes, no networking change, and so on (but i think it would be ok new drivers since they cant be disabled or simply not used)
and .19 would come out months after the .14 release
it's not a stable/devel or 2.6/2.7 or better 2.4/2.5 scheme (even a 2.6/2.7 scheme almost exists with main tree/-mm tree atm) or old stuff under a different point of view BUT it's the SAME current dev model applied to every release EXCEPT for the last one BEFORE the 6months timeline.
what does it means: no one says nothing is unacceptable, it means things could be better for distros/users/external kernel projects by doing something that could be called a two-layers model:
--------------------
Linus & co. "hey, let's write down the major features for the next 6 months and plan things a little"
--------------------
Other kernel developers "I would like to get in X, Y and Z. Let's do it 2.6.x style."
--------------------
The changed versioning scheme just reflects the 6months release ciclye idea. fullstop.
trying to clarify again:
Quoted 4 lines
What you're suggesting sounds just like going back to the old style of development where 2.<even>.x is stable, and 2.<odd>.x is development. You might as well just suggest that after 2.6.16, we fork to 2.7.0, and 2.6.17+ will be stable increments like we always used to do.
every 2.6.N.x release would be the SAME as a 2.6.x release. The entire 6months cycle puts in some time/features/stability boundaries on top of the existent model. Finally, those stability boundaries would be planned every 6months assuring the best fit of the model with developers, distros and users needs.
hope I clarified,
Michele
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lee RevellQuoted 9 lines · Lee Revell
You seem to be saying that the current development model is unacceptable for users for whom older kernel work just fine, and the main risk in upgrading is regression. But the new development model is clearly needed for those users whose needs are not met by the old kernel, say due to unacceptable soft RT performance or unsupported hardware.
But it's wrong to try to evenly balance the needs of these two classes of users, because the first class has another option - they can stick with the old kernel that works for them. The second class of users has
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 12 lines · Matthias Andree
Quoted 9 lines · Lee Revell
You seem to be saying that the current development model is unacceptable for users for whom older kernel work just fine, and the main risk in upgrading is regression. But the new development model is clearly needed for those users whose needs are not met by the old kernel, say due to unacceptable soft RT performance or unsupported hardware.
But it's wrong to try to evenly balance the needs of these two classes of users, because the first class has another option - they can stick with the old kernel that works for them. The second class of users has
Quoted 7 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
If you want security fixes backported then you can get a distro kernel.
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Lee Revell:
Quoted 9 lines
Quoted 7 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
If you want security fixes backported then you can get a distro kernel.
And these distro kernels appear magically from nowhere?
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 10 lines · Florian Weimer
* Lee Revell:
Quoted 8 lines
Quoted 7 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
Quoted 4 lines
Quoted 1 line
If you want security fixes backported then you can get a distro kernel.
And these distro kernels appear magically from nowhere?
No you get them from Red Hat or SuSE or whoever. One of the core assumptions of the new development model is that distros whose business model involves paying people to do QA and regression testing and have access to bug reports from zillions of users are better positioned than kernel developers to decide what a "stable" kernel is.
Lee
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Lee Revell:
Quoted 11 lines · Florian Weimer
Quoted 10 lines
* Lee Revell:
Quoted 8 lines
Quoted 7 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
If you want security fixes backported then you can get a distro kernel.
And these distro kernels appear magically from nowhere?
No you get them from Red Hat or SuSE or whoever.
"Whoever"? Debian? Slackware? Gentoo? Even companies like SGI might have difficulties providing security support for their custom kernels, not to speak of tons of embedded developers.
Can I buy security support for my custom MIPS kernel, like I can buy GCC support for the platform? Is there a similar market?
Quoted 5 lines
One of the core assumptions of the new development model is that distros whose business model involves paying people to do QA and regression testing and have access to bug reports from zillions of users are better positioned than kernel developers to decide what a "stable" kernel is.
But they aren't more qualified when it comes to extracting security fixes (and other critical bug fixes). For picking functionality, I agree, but critical bug fixes which basically affect everone are a different matter. It doesn't make sense to redo the same analysis over and over again, at each vendor.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
On Tue, 2005-12-06 at 00:00 +0100, Florian Weimer wrote:
[...]
Quoted 4 lines
fixes (and other critical bug fixes). For picking functionality, I agree, but critical bug fixes which basically affect everone are a different matter. It doesn't make sense to redo the same analysis over and over again, at each vendor.
Then vendors should cooperate/collaborate. Where's the problem?
Bernd
Signature · 3 lines
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and ServicesRe: RFC: Starting a stable kernel series off the 2.6 kernel
* Bernd Petrovitsch:
Quoted 8 lines · Florian Weimer
[...]
Quoted 4 lines
fixes (and other critical bug fixes). For picking functionality, I agree, but critical bug fixes which basically affect everone are a different matter. It doesn't make sense to redo the same analysis over and over again, at each vendor.
Then vendors should cooperate/collaborate. Where's the problem?
Usually, publicly visisble security bug handling is not separated from the main development effort, especially if there is already a centralized team for that purpose.
It's also a waste of resources if someone with no detailed knowledge of the first analysis (which was made when the bug was fixed) or the source code in question has to redo the whole analysis, just to pick up the correct patches and classify the vulnerability. If you duplicate the work just once, things are a bit better, but it's still a waste of resources, and people not familiar with the code tend to make more mistakes.
It's not that there isn't any cooperation, either. As far as I can tell, it's possible to get most insider know-how on vulnerabilities once it is published. It's just more time-consuming than necessary.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias Andree* Matthias Andree:
Quoted 6 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
Well, if there's a CVE name, the proper patch isn't *that* far away (someone has already done a bit of work to isolate the fix). The real issue seems to be how to make sure that CVE names are assigned during the kernel development process (and not just as an afterthought by the security folks).
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Florian Weimer
* Matthias Andree:
Quoted 6 lines
The point that just escaped you as the motivation for this thread was the availability of security (or other critical) fixes for older kernels. It would all be fine if, say, the fix for CVE-2004-2492 were available for those who find 2.6.8 works for them (the fix went into 2.6.14 BTW), and the concern is the development model isn't fit to accomodate needs like this.
Quoted 5 lines
Well, if there's a CVE name, the proper patch isn't *that* far away (someone has already done a bit of work to isolate the fix). The real issue seems to be how to make sure that CVE names are assigned during the kernel development process (and not just as an afterthought by the security folks).
[email protected] works that way already in a way. Of course it'd be nice to add a cve name while coding the security hole into the kernel, but nobody is that clearvoyant ;) The hardest part is actually knowing which versions are affected, especially when the code no longer quite is the same, the locking rules got cleaned up in later versions (which means the older kernel was a mess, so you're always looking at more messy code than the "new" kernel). For some stuff this is easy. For other stuff it for sure isn't, especially if you want to keep api/abi compatibility, or at least low impact. Some security fixes just are invasive. Those are rare, maybe 2 or 3 times a year or so. But they do exist... unfortunate as it is. The irony is that doing a "hacky" less invasive risk actually may introduce more risk to stability than doing the full invasive fix. Nasty trade-offs there....
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Arjan van de Ven:
Quoted 7 lines
Quoted 5 lines
Well, if there's a CVE name, the proper patch isn't *that* far away (someone has already done a bit of work to isolate the fix). The real issue seems to be how to make sure that CVE names are assigned during the kernel development process (and not just as an afterthought by the security folks).
[email protected] works that way already in a way.
As far as I know, many of the recent CVE assignments for kernel vulnerabilities have been done by MITRE, requested by individuals which are neither known as kernel developers, nor vendor security folks (for "vendor" as in "we have our own legal department with real lawyers").
Maybe the source of CVE assignments paints a wrong picture. But if the CVE picture is correct, vendor-paid kernel developers help behind the scenes, but there is little interest in openly documenting security issues, so that users (and what kernel.org considers fringe distros) can apply the relevant patches if they use kernel.org kernels.
Quoted 1 line
From a vendor POV, the lack of official kernel.org advisories may be a
feature. I find it rather disturbing, and I'm puzzled that the kernel developer community doesn't view this a problem. I know I'm alone, and there are certainly part-time security guys who would be willing join forces to create something like a kernel.org security bug database. But the only answers we get is that everything is fine, vendors handle the situation, [email protected] actually does this already, etc.
Quoted 1 line
The hardest part is actually knowing which versions are affected,
First, you need to know that the patch plugs a security hole. 8-) This isn't always obvious based on the patch, even if the fact is known to the comitter.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 3 lines · Florian Weimer
From a vendor POV, the lack of official kernel.org advisories may be a feature. I find it rather disturbing, and I'm puzzled that the kernel developer community doesn't view this a problem. I know I'm alone,
You're not alone in viewing this as a problem, but QA is a burden kernel developers are not interested in. But it is necessary.
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Matthias Andree:
Quoted 7 lines · Florian Weimer
Quoted 4 lines
From a vendor POV, the lack of official kernel.org advisories may be a feature. I find it rather disturbing, and I'm puzzled that the kernel developer community doesn't view this a problem. I know I'm alone,
You're not alone in viewing this as a problem,
I know, it's a typo.
Quoted 4 lines
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
There are critical kernel parts for which automated regression testing is very hard. In some twisted sense, regression testing ist best done by those who run real applications, i.e. end users. The interesting thing is that you end up with reasonably stable software this way, except in a few corner cases.
The main point of debate seems to be how relevant the corner cases are, and how much general kernel development should care about them. (And no, not everyone in such a corner has $$,$$$ to spend.)
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 8 lines · Matthias Andree
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
People who pass the changes can only test ones they have hardware for. For the rest they can try to validate the code by reading patches but have to rely on the submitter wrt to the patch actually working.
--
Dmitry
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines · Dmitry Torokhov
Quoted 4 lines · Matthias Andree
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
Quoted 8 lines
Quoted 4 lines
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
People who pass the changes can only test ones they have hardware for. For the rest they can try to validate the code by reading patches but have to rely on the submitter wrt to the patch actually working.
What I'm saying is that people (maintainer) should have a selected number of people (users) test the patches before they are merged.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 12 lines · Matthias Andree
Quoted 10 lines · Dmitry Torokhov
Quoted 8 lines · Matthias Andree
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
Quoted 7 lines
Quoted 3 lines
People who pass the changes can only test ones they have hardware for. For the rest they can try to validate the code by reading patches but have to rely on the submitter wrt to the patch actually working.
What I'm saying is that people (maintainer) should have a selected number of people (users) test the patches before they are merged.
And we try. Take for example psmouse_resync patch that is now in -mm. I got about 30 reports that it worked and fixed people's problems before I got it to Andrew. And still as soon as it got to -mm I got a complaint that it failed on one of boxes ;(
Signature · 1 line
Dmitry
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 8 lines · Dmitry Torokhov
Quoted 2 lines · Matthias Andree
What I'm saying is that people (maintainer) should have a selected number of people (users) test the patches before they are merged.
And we try. Take for example
psmouse_resyncpatch that is now in -mm. I got about 30 reports that it worked and fixed people's problems before I got it to Andrew. And still as soon as it got to -mm I got a complaint that it failed on one of boxes ;(
The important thing is to get these failing boxes into the regular test set. I know that's not always easy, because end users tend to go away as soon as it works again for them.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Matthias AndreeQuoted 7 lines · Matthias Andree
Quoted 3 lines · Florian Weimer
From a vendor POV, the lack of official kernel.org advisories may be a feature. I find it rather disturbing, and I'm puzzled that the kernel developer community doesn't view this a problem. I know I'm alone,
You're not alone in viewing this as a problem, but QA is a burden kernel developers are not interested in. But it is necessary.
If you want to run a big automated regression test against the kernel, exercising the full API and immediately catching any regressions, go right ahead. Nobody's stopping you and you don't need our permission anyway. The Linux Test Project is working on something like this already, and ODSL does some of this to. (It's not like QA is being ignored.)
The problem is that the bulk of the kernel code is device drivers, and nobody has all the strange and esoteric hardware that the drivers push. Nope, not even IBM. I doubt any one organization anywhere on the planet has _everything_ the kernel has been used to drive.
.
Quoted 7 lines
QA has to happen at all levels if it is supposed to be affordable or scalable. The development process was scaled up, but QA wasn't.
How about the Signed-off-by: lines? Those people who pass on the changes also pass on the bugs, and they are responsible for the code - not only license-wise, but also quality-wise. That's the latest point where regression tests MUST happen.
I can't test your setup for you. I haven't got your setup. All I can tell you is that it worked for me.
I spent most of a week last month fighting to get User Mode Linux 2.6.15-rc1 through rc4 to compile and run on both x86 ubuntu and x86-64 PLD. Different versions of GCC compiled the darn interface code differently (there's a section where it switches stacks and gcc kept trying to touch the stack in the middle of this, and segfaulting). Worked fine for Jeff Dike and Blaisorblade, because they weren't using a semi-obsolete version of ubuntu.
Over on PLD, I had a fight just to get it to _compile_, because the header files were all different (PLD uses Mazur's cleaned up 2.6 headers which uClibc systems also use, while most things use the glibc package, and at one point they had userspace and kernel space headers reversed and it worked fine with the glibc kernel headers but Mazur's headers really are cleaned up and don't leak nearly so much kernel stuff into userspace). And then /lib wasn't a symlink to /lib64 (it is on Fedora and Debian, but on PLD they're separate directories) so the link path had to be adjusted (/lib64 was the correct directory for a 64-bit build and should be checked first). Then getting it to run had another half-dozen problems with various interface code: for some reason on PLD page_size was linked as a function call when they expected it to be a constant...
Another fun little thing is just a performance issue: UML gets its "physical memory" from an mmap file (easy to share between processes), but if that file isn't on tmpfs then every page UML dirties gets scheduled for writeout, over and over again, keeping the hard drive constantly busy and slowing the system
to a crawl. Of course it _works_, but so it's hard to pin down what the
problem is. (UML isn't slowed down, the rest of the system is by the unnecessary I/O.) Again, on Jeff's system /tmp is a tmpfs mount. On most systems, /dev/shm is a tmpfs mount and /tmp inherits /. (Meaning on knoppix it's tmpfs, but on Fedora or Ubuntu or Gentoo, it isn't by default. Unless the sysadmin has changed it, which many sysadmins will.) And strangely, on the PLD system I'm borrowing /dev/shm isn't tmpfs, so changing the default is the right thing but it needed an improved error message.
It all worked just _fine_ for the people who wrote it. (And continues to.) And all of this is why there was an -rc1, so people like me could try it and report that it didn't work the same way for us and spend a week figuring out all the various different _ways_ it didn't work.
This isn't the full set of bugs I plowed through. I had a version at one point that ran fine, gave me a command shell (init=/bin/sh) and I reported success and then came back the next day with "nope, fork segfaults". (Actually it was exec segfaulting.) The shell _did_ come up fine. (And echo $USER hadn't actually had to exec anything...) But that wasn't the end of it.
The thing is, me spending all this time making sure it worked _for_me_ was something that I did on my own time, voluntarily. I'm not really a UML developer, I have too much to do elsewhere. If I hadn't done this, would it work on ubuntu and PLD right now? Maybe. I don't know. But it already worked for Jeff Dike when he checked it in. Worked just fine. Because he didn't have the environment I had. He could find _none_ of these problems because the bugs only manifest in an environment he doesn't have.
And all this is a _rounding_error_ compared to the kernel as a whole. This is just one little corner of it, in one little release, where one person spent one week debugging on just two systems.
And this wasn't even hardware dependent! (Or an intermittent problem that you _think_ is fixed because you haven't seen it, or something requiring a particularly arduous reproduction sequence like a 40 hour calculation, or access to a machine that's only available thursdays from 2-4 am...)
You seem to _deeply_ misunderstand nature of the problem.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Florian WeimerQuoted 5 lines · Florian Weimer
As far as I know, many of the recent CVE assignments for kernel vulnerabilities have been done by MITRE, requested by individuals which are neither known as kernel developers, nor vendor security folks (for "vendor" as in "we have our own legal department with real lawyers").
Most of them will be because vendors employ security professionals to handle security CVE work and do all the tedious and terribly important tracking of bugs v releases and what needs to be fixed by whom and when
- and developers to write code.
Quoted 6 lines
Maybe the source of CVE assignments paints a wrong picture. But if the CVE picture is correct, vendor-paid kernel developers help behind the scenes, but there is little interest in openly documenting security issues, so that users (and what kernel.org considers fringe distros) can apply the relevant patches if they use kernel.org kernels.
The 2.6.x.y maintainers are directly involved in [email protected] last time I checked.
Quoted 3 lines
database. But the only answers we get is that everything is fine, vendors handle the situation, [email protected] actually does this already, etc.
Having someone doing that on kernel.org sounds a good plan
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Ben CollinsQuoted 4 lines · Ben Collins
What you're suggesting sounds just like going back to the old style of development where 2.<even>.x is stable, and 2.<odd>.x is development. You might as well just suggest that after 2.6.16, we fork to 2.7.0, and 2.6.17+ will be stable increments like we always used to do.
I'll let him speak to what he intended, but my idea of stable is to keep the features of 2.6.0 in 2.6.N for any value of N. Adding new stuff rapidly hasn't been nearly the problem people feared, but that's largely due to the efforts of akpm to act as throttle, and somehow get more people to try his versions and knock the corners off the new code before it goes mainline.
I do think the old model was better; by holding down major changes for six months or so after a new even release came out, people had a chance to polich the stable release, and developers had time to recharge their batteries so to speak, and to sit and think about what they wanted to do, without feeling the pressure to write code and submit it right away. Knowing that there's no place to send code for six months is a great aid to generating GOOD code.
The other advantage of a development tree was that features could be added and removed without the argument that it would break this or that. It was development, no one was supposed to use it for production, no one could claim that there was even an implied promise of things working or even existing. ipchains could have gone out of 2.6 with no more fuss than xiafs departing. The people who really want it stay with the old kernel.
To a large extent -mm has become the development kernel, and as neat as that is, a development model which depends on a small number of dedicated and talented people to make it work is fragile.
Just my thoughts, I think we had it right before, I think it's less inherently stable now.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 1 line · Bill Davidsen
I do think the old model was better; by holding down major changes for six months or so after a new even release came out, people had a chance to polich the stable release, and developers had time to recharge their batteries so to speak, and to sit and think about what they wanted to do, without feeling the pressure to write code and submit it right away. Knowing that there's no place to send code for six months is a great aid to generating GOOD code.
It never worked that way, which is why the model changed.
Like it or not, developers would only focus on one release. In the old model, unstable things would get shoved into the stable kernel, because people didn't want to wait six months. And for the unstable kernel, it would often be so horribly broken that even developers couldn't use it for development (think 2.5.x IDE).
Jeff
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Jeff Garzik
Quoted 7 lines · Bill Davidsen
I do think the old model was better; by holding down major changes for six months or so after a new even release came out, people had a chance to polich the stable release, and developers had time to recharge their batteries so to speak, and to sit and think about what they wanted to do, without feeling the pressure to write code and submit it right away. Knowing that there's no place to send code for six months is a great aid to generating GOOD code.
Quoted 7 lines
It never worked that way, which is why the model changed.
Like it or not, developers would only focus on one release. In the old model, unstable things would get shoved into the stable kernel, because people didn't want to wait six months. And for the unstable kernel, it would often be so horribly broken that even developers couldn't use it for development (think 2.5.x IDE).
So why haven't the broken patches (yes, TCQ and all that, too) been backed out at the time?
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Jeff GarzikQuoted 8 lines · Jeff Garzik
Quoted 1 line · Bill Davidsen
I do think the old model was better; by holding down major changes for six months or so after a new even release came out, people had a chance to polich the stable release, and developers had time to recharge their batteries so to speak, and to sit and think about what they wanted to do, without feeling the pressure to write code and submit it right away. Knowing that there's no place to send code for six months is a great aid to generating GOOD code.
It never worked that way, which is why the model changed.
Like it or not, developers would only focus on one release. In the old model, unstable things would get shoved into the stable kernel, because people didn't want to wait six months. And for the unstable kernel, it would often be so horribly broken that even developers couldn't use it for development (think 2.5.x IDE).
I was actually thinking of Rusty's module code... I do every time I have to build an initrd file by hand "Although the syntax is similar to the older /etc/modules.conf, there are many features missing."
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 9 lines · Bill Davidsen
Quoted 4 lines · Ben Collins
What you're suggesting sounds just like going back to the old style of development where 2.<even>.x is stable, and 2.<odd>.x is development. You might as well just suggest that after 2.6.16, we fork to 2.7.0, and 2.6.17+ will be stable increments like we always used to do.
I'll let him speak to what he intended, but my idea of stable is to keep the features of 2.6.0 in 2.6.N for any value of N.
That works iff N == 0.
Quoted 2 lines
Adding new
stuff rapidly hasn't been nearly the problem people feared,
... because they had the leeway to change broken/unsuitable things to fit, and because the tools today are so much better...
Quoted 4 lines
but that's
largely due to the efforts of akpm to act as throttle, and somehow get more people to try his versions and knock the corners off the new code before it goes mainline.
Heroic efforts, sure.
Quoted 1 line
I do think the old model was better;
It just /didn't work/. You don't remember the pain of jumping from 2.2 to 2.4, do you? Sure, while 2.2 lasted it was stable, but everybody screamed that the latest&greatest whatever-card didn't work, and either jumped to 2.3.x du jour (good luck! had to futz around with lots of matching userland changes /without/ distro support for that) or choose a distro which shipped a patched 2.3 kernel (which was totally incompatible when 2.4 showed up) or (tried to) backport features to 2.2 (ditto, resulting from a /huge/ amount of wasted effort).
Quoted 3 lines
by holding down major changes for
six months or so after a new even release came out, people had a chance to polich the stable release,
No chance. The people who would have been doing so just got bored and looked elsewhere for challenges. Do enough of that, and you'll be left without any volunteers at all.
Quoted 4 lines
and developers had time to
recharge their batteries so to speak, and to sit and think about what they wanted to do, without feeling the pressure to write code and submit it right away.
This assumes kernel development is uniform movement. Far from it, at any moment there are pieces that haven't been touched in ages, others in active turnover, others just finished being worked over.
Quoted 2 lines
Knowing that there's no place to send code for
six months is a great aid to generating GOOD code.
For something else, sure.
Quoted 5 lines
The other advantage of a development tree was that features could be added and removed without the argument that it would break this or that. It was development, no one was supposed to use it for production, no one could claim that there was even an implied promise of things working or even existing.
With the current tools, that development can be done outside the vanilla tree, and integrated with not too much pain. The /reason/ for "wild development" phases is not there anymore.
Quoted 3 lines
ipchains could have gone out of
2.6 with no more fuss than xiafs departing. The people who really want it stay with the old kernel.
Come on, it has been announced for a /long/ time. It is not like anybody could have been caught unaware. More like people thinking it would /never/ be done as it was called so long before...
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkHi Adrian,
I would really appreciate such a move to a stable series.
I've had some really bad luck with instability of 2.6.x - in particular with NFS.
Would such a stable kernel keep up to date on basic drivers?
I ask since I got into a messy situation on a series of production servers; they were really new Dell servers using standard Intel chipsets but needed SATA stuff that went in recently. Does 2.6.16 have the basic infrastructure for all the current hardware so that if you branch now you aren't going to have to do any really heavy backports to be able to run on 'current' hardware?
I hit the situation where I have a 2.6.5 kernel I use on everything else and whose NFS works fine; and 2.6.11 or newer which supports the hardware - but whose NFS is giving me broken locking to some obscure systems.
IMHO we've also got into a real mess where it is vendor kernels that have stability fixes in for many things (NFS in particular) - but the lkml doesn't want to know about vendor kernels, but at the same time they aren't up for stabilisation.
Good luck with such a branch!
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 10 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)
Your problem statement is correct, but you're fixing the symptoms, not the cause.
What we need is an easier way for users to pull in kernel updates with the matching kernel-related user-space.
This is provided, though with some lag, by Fedora, openSUSE, Debian testing, dare I say gentoo and others.
The right way to address this is to work with the distribution of your choice to make these updates available faster.
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 16 lines · Lars Marowsky-Bree
Quoted 10 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)Your problem statement is correct, but you're fixing the symptoms, not the cause.
Quoted 8 lines
What we need is an easier way for users to pull in kernel updates with the matching kernel-related user-space.
This is provided, though with some lag, by Fedora, openSUSE, Debian testing, dare I say gentoo and others.
The right way to address this is to work with the distribution of your choice to make these updates available faster.
The big problem is though that we don't typically find out that we've regressed until after a kernel update is in the end-users hands.
In many cases, submitters of changes know that things are going to break. Maybe we need a policy that says changes requiring userspace updates need to be clearly documented in the mails Linus gets (Especially if its a git pull request), so that when the next point release gets released, Linus can put a section in the announcement detailing what bits of userspace are needed to be updated.
It still isn't to solve the problem of regressions in drivers, but that's a problem that's not easily solvable.
Dave
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 9 lines · Dave Jones
The big problem is though that we don't typically find out that we've regressed until after a kernel update is in the end-users hands.
In many cases, submitters of changes know that things are going to break. Maybe we need a policy that says changes requiring userspace updates need to be clearly documented in the mails Linus gets (Especially if its a git pull request), so that when the next point release gets released, Linus can put a section in the announcement detailing what bits of userspace are needed to be updated.
True, but this first block doesn't really qualify as a "regression". Yes, a clearer-than-crystal documentation of "this kernel requires user-space component foo to be at least x.y.z if feature bar is used" would go a long way.
And if then user-space itself was tolerant of at least version N and N-1, then users could even roll back one kernel version if problems arise.
Both of these are documentation and user-space issues, and don't much depend on changes to kernel development model.
Quoted 2 lines
It still isn't to solve the problem of regressions in drivers, but that's a problem that's not easily solvable.
True. Regressions will always occur when driver updates happen. There'll always be the next bug. I don't think anyone introduces these on purpose ;-)
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
[OT] Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · you
Quoted 2 lines
It still isn't to solve the problem of regressions in drivers, but that's a problem that's not easily solvable.
True. Regressions will always occur when driver updates happen. There'll always be the next bug. I don't think anyone introduces these on purpose ;-)
From the dmesg of the openwrt project:
[snip]
802.1Q VLAN Support v1.8 Ben Greear <[email protected]> All bugs added by David S. Miller <[email protected]>
VFS: Mounted root (squashfs filesystem) readonly. [snap]
Smash him. :D
Signature · 1 line
Greetings Michael.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lars Marowsky-BreeQuoted 17 lines · Lars Marowsky-Bree
Quoted 9 lines · Dave Jones
The big problem is though that we don't typically find out that we've regressed until after a kernel update is in the end-users hands.
In many cases, submitters of changes know that things are going to break. Maybe we need a policy that says changes requiring userspace updates need to be clearly documented in the mails Linus gets (Especially if its a git pull request), so that when the next point release gets released, Linus can put a section in the announcement detailing what bits of userspace are needed to be updated.
True, but this first block doesn't really qualify as a "regression". Yes, a clearer-than-crystal documentation of "this kernel requires user-space component foo to be at least x.y.z if feature bar is used" would go a long way.
Quoted 7 lines
And if then user-space itself was tolerant of at least version N and N-1, then users could even roll back one kernel version if problems arise.
Both of these are documentation and user-space issues, and don't much depend on changes to kernel development model.
...
One effect that you mustn't underestimate is that if people had to got to N-1 for two or three different N due to different regressions in different kernels, they might decide to stay with kernel version M even though kernel M+10 might have been released and version M lacks tons of security fixes.
Quoted 2 lines
Sincerely,
Lars Marowsky-Brée <[email protected]>
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Dave JonesQuoted 6 lines · Dave Jones
In many cases, submitters of changes know that things are going to break. Maybe we need a policy that says changes requiring userspace updates need to be clearly documented in the mails Linus gets (Especially if its a git pull request), so that when the next point release gets released, Linus can put a section in the announcement detailing what bits of userspace are needed to be updated.
This isn't acceptable in stable kernels. FreeBSD has a very tight policy, newer kernels off the same branch support older user space. The upgrade path is clear, reboot into new kernel, have it spit a few reminders that your userspace needs update (Linux also has this, for instance, with SG_IO and its predecessors) but still everything works.
Requiring new userspace at a patchlevel kernel upgrade is nothing but impertinent, unless that updated userspace ships as part of the kernel.
Quoted 2 lines
It still isn't to solve the problem of regressions in drivers, but that's a problem that's not easily solvable.
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 11 lines · Matthias Andree
Quoted 6 lines · Dave Jones
In many cases, submitters of changes know that things are going to break. Maybe we need a policy that says changes requiring userspace updates need to be clearly documented in the mails Linus gets (Especially if its a git pull request), so that when the next point release gets released, Linus can put a section in the announcement detailing what bits of userspace are needed to be updated.
This isn't acceptable in stable kernels. FreeBSD has a very tight policy, newer kernels off the same branch support older user space.
The BSDs have an advantage in that their userspace & kernels are closely coupled. When kernel changes need a userspace change, it gets done at the same time in the same repository.
Dave
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Lars Marowsky-Bree* Lars Marowsky-Bree:
Quoted 2 lines
The right way to address this is to work with the distribution of your choice to make these updates available faster.
Working with a distribution benefits that distribution alone. Working on (e.g.) kernel security advisories would benefit everyone. It's not a speed issue, it's more about coverage. And full coverage is very hard to get without support from the real developers.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 6 lines · Florian Weimer
Quoted 2 lines
The right way to address this is to work with the distribution of your choice to make these updates available faster.
Working with a distribution benefits that distribution alone. Working on (e.g.) kernel security advisories would benefit everyone. It's not a speed issue, it's more about coverage. And full coverage is very hard to get without support from the real developers.
The distributions differ from another in their sync and branch points from the main kernel, and there's no way before hell freezes over this is going to change.
So, you essentially need to maintain the kernel your distribution branched from. This means: backport fixes/features relevant to your release, and make sure the rest of the system stays in sync. This puts the effort there where it belongs: to those people benefitting from it.
The current model actually works _better_ for the existing distributions, because they get to choose their branchpoint - with all the features up to that point - instead of having, say, 2.6.x as the stable base and then already starting out with having to backport major features from 2.7 (because of user demand).
A single stable branch beneficial to all users means frozen innovation for the distributions, and they still have to significant QA on the releases and the updates to that kernel (to stay on that issue, it applies to other major components too). Even with 2.4.x, a distribution couldn't simply stick in newer 2.4.x+n releases instead of 2.4.x, because, as someone already so well said, one users bugfix is another's regression. And all the distributors would have to agree on the same policy for kernel changes and sync even updates!
Thus, more effort for less gain.
The truth is that right now we have _several_ stable branches maintained by the distributors (be they commercial or free) together with the kernel-related user-land.
I daresay this is a feature and works pretty well.
If someone wants to maintain a stable 2.6.x release, nobody will stop them from maintaining 2.6.x.y until y overflows, or until the 6 months are full and then they can release their new major update and plot a transition path with the updates to all required user-land.
The fact people are complaining about stems from the fact that the Linux kernel itself is useless; it is intimately tied to various components which reside in user-space, and so it is inherent to the process that a major kernel update very likely maps to a distribution update. The components are developed separately, but they do not have a stable modular interface, at essentially no level but the POSIX/system call interfaces and sometimes, glibc or what is specified in the LSB.
This is a _feature_! It allows us to more quickly move and adapt. The BSD model is, as Dave pointed out, even further along this road, and every distribution basically does exactly that, because our user community is big enough to sustain it.
Sincerely,
Lars Marowsky-Brée
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
Re: RFC: Starting a stable kernel series off the 2.6 kernel
* Lars Marowsky-Bree:
Quoted 9 lines · Florian Weimer
Quoted 7 lines
Quoted 3 lines
The right way to address this is to work with the distribution of your choice to make these updates available faster.
Working with a distribution benefits that distribution alone. Working on (e.g.) kernel security advisories would benefit everyone. It's not a speed issue, it's more about coverage. And full coverage is very hard to get without support from the real developers.
Quoted 8 lines
The distributions differ from another in their sync and branch points from the main kernel, and there's no way before hell freezes over this is going to change.
So, you essentially need to maintain the kernel your distribution branched from. This means: backport fixes/features relevant to your release, and make sure the rest of the system stays in sync. This puts the effort there where it belongs: to those people benefitting from it.
Lars, please read again what I wrote. It's not about branch maintenance ("here's the patch"), it's about providing basic information which can guide branch maintenance ("here's an issue you need to look at if you use code from the IPv6 stack in version 2.6.10 to 2.6.12").
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 4 lines
These problems follow from the development model.
Hi!
I am not evil or unsatisfied end-user by any means, it is just quite interesting to follow today's lkml posts.
After reading "Linux 2.6.15-rc5: off-line for a week" from Torvalds it seems like this:.
a) Torvalds thinks that nobody cares about kernel testing
b) other gurus (they are also only "on-line" testers nowadays) doesn't feel good with development model (or at least they have no resources to do testing [Torvalds])
c) end-users (or those who are not kernel maintainers) are directed permanently to distros kernels and "stay away from kernel.org you wanna-bees!"
I can't say is it good or bad but this is interesting at least. I hope you guys keep going!
Have a nice day!
Indrek
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 5 lines
nt model (or at least they have no resources to
do testing [Torvalds])
c) end-users (or those who are not kernel maintainers) are directed permanently to distros kernels and "stay away from kernel.org you wanna-bees!
this is not what is being said. What is being said is that if you can't deal with occasional breakage, you're better off using vendor kernels. But.. if you can't deal with occasional breakage, you wouldn't test test kernels EITHER. If you can deal with an occasional breakage, I hope you and everyone else who can, will run and test kernel.org kernels, especially the -rc ones.
Most of the "instability" people complain about with the new 2.6 model is caused by people not testing the -rc kernels before they are released, so that they end up being released with regressions. But... that will happen no matter what model you use actually. Before july there was a problem where -rc kernels kept changing bigtime, so it was hard to know which one to test if you only had time to test one, but that is now changed...
Maybe it's a bit extremist, but I'd like to even state it like this:
"If you can't be bothered to test -rc kernels, you have no right to complain about the final ones", sort of as analogy to the "if you don't go voting you have no right to complain about the politicians".
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 12 lines · Arjan van de Ven
Quoted 4 lines
nt model (or at least they have no resources to do testing [Torvalds])
c) end-users (or those who are not kernel maintainers) are directed permanently to distros kernels and "stay away from kernel.org you wanna-bees!this is not what is being said. What is being said is that if you can't deal with occasional breakage, you're better off using vendor kernels. But.. if you can't deal with occasional breakage, you wouldn't test test kernels EITHER. If you can deal with an occasional breakage, I hope you and everyone else who can, will run and test kernel.org kernels, especially the -rc ones.
Quoted 4 lines
Most of the "instability" people complain about with the new 2.6 model is caused by people not testing the -rc kernels before they are released, so that they end up being released with regressions.
I think I have seen special live-cd distribution for KDE beta testers. Kernel is not a KDE but such a very broken distribution with -rc kernel could be more easily maintained than "udev forever!". Live-cd (or live-usb) wouldn't be too flexible - you can't say there "can you give a whirl to this patch, please" but I bet you will have more testers.
thanks,
Indrek
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Indrek KruusaQuoted 10 lines · Indrek Kruusa
After reading "Linux 2.6.15-rc5: off-line for a week" from Torvalds it seems like this:.
a) Torvalds thinks that nobody cares about kernel testing
b) other gurus (they are also only "on-line" testers nowadays) doesn't feel good with development model (or at least they have no resources to do testing [Torvalds])
c) end-users (or those who are not kernel maintainers) are directed permanently to distros kernels and "stay away from kernel.org you wanna-bees!"
Yeah, normally this would mean it's a tuesday. We're running a little early.
Rob
Signature · 2 lines
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means.
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 8 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace (e.g. for udev or the pcmcia tools switch)One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
Depending on where you work, "not working" may be acceptable vs. "working with a known security hole."
Quoted 5 lines
These problems follow from the development model.
The latest stable kernel series without these problems is 2.4, but 2.4 is becoming more and more obsolete and might e.g. lack driver support for some recent hardware you want to use.
Quoted 8 lines
Since Andrew and Linus do AFAIK not plan to change the development model, what about the following for getting a stable kernel series without leaving the current development model:
Kernel 2.6.16 will be the base for a stable series.
After 2.6.16, there will be a 2.6.16.y series with the usual stable rules.
After the release of 2.6.17, this 2.6.16.y series will be continued with more relaxed rules similar to the rules in kernel 2.4 since the release of kernel 2.6.0 (e.g. driver updates will be allowed).
Actually I would be happy with the stability of this series if people would stop trying to take working features OUT of it! That's the largest problem I see, not that the existing features are unstable, and we have a -stable branch to cover that, but that I can't count on features I use and which are required for useful work.
If a firm policy of not removing supported features until 2.7 was adopted I don't see a problem. The bulk of the instability (not absolutely all, I grant), is in new features, or features which aren't working all that well in any case. But if existing features suddenly drop out from beneath the user, then you will find people doing what you mentioned, staying with old kernels with holes rather than moving to kernels which are simply no longer functional.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 7 lines · Bill Davidsen
Actually I would be happy with the stability of this series if people would stop trying to take working features OUT of it! That's the largest problem I see, not that the existing features are unstable, and we have a -stable branch to cover that, but that I can't count on features I use and which are required for useful work.
Quoted 7 lines
If a firm policy of not removing supported features until 2.7 was adopted I don't see a problem. The bulk of the instability (not absolutely all, I grant), is in new features, or features which aren't working all that well in any case. But if existing features suddenly drop out from beneath the user, then you will find people doing what you mentioned, staying with old kernels with holes rather than moving to kernels which are simply no longer functional.
You are thinking in terms of the old development model.
This is not an option since the current development model says that there might never be a 2.7 kernel series.
We might like it or not, but this is the current development model and Andrew and Linus don't seem to want to change it.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 2 lines · Bill Davidsen
If a firm policy of not removing supported features until 2.7 was adopted I don't see a problem. The bulk of the instability (not
I do - the problem is someone will let it bit-rot for a few releases and then declare it broken. Remember ATAPI CD writing vs. DMA?
Signature · 1 line
Matthias Andree
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Bill DavidsenQuoted 2 lines · Bill Davidsen
Actually I would be happy with the stability of this series if people would stop trying to take working features OUT of it!
Features are removed when they are no longer features, but design irritations in a new and improved design, and usually, equivalent or better (or at least thought to be) functionality is available still in the big picture (which includes user-space), hopefully in a cleaner place.
Now, design is often a holy war, and people disagree. That's fine and to be expected. And sometimes, the whole solution takes a while to materialize and be implemented from the kernel up to all user-space and even longer until it has been implemented in the brains of the admins. This, too, is fine and expected. It's called "innovation" and "development", sometimes iterative.
Quoted 4 lines
working all that well in any case. But if existing features suddenly drop out from beneath the user, then you will find people doing what you mentioned, staying with old kernels with holes rather than moving to kernels which are simply no longer functional.
You're assuming the kernel is both "static" design-wise as well as independent (or at least basically eternally backwards compatible) from user-space. Both assumptions are no longer true. Get over it.
Sincerely,
Lars Marowsky-Brée
Signature · 4 lines
High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 12 lines · Lars Marowsky-Bree
Quoted 1 line · Bill Davidsen
Actually I would be happy with the stability of this series if people would stop trying to take working features OUT of it!
Features are removed when they are no longer features, but design irritations in a new and improved design, and usually, equivalent or better (or at least thought to be) functionality is available still in the big picture (which includes user-space), hopefully in a cleaner place.
Quoted 6 lines
Now, design is often a holy war, and people disagree. That's fine and to be expected. And sometimes, the whole solution takes a while to materialize and be implemented from the kernel up to all user-space and even longer until it has been implemented in the brains of the admins. This, too, is fine and expected. It's called "innovation" and "development", sometimes iterative.
Removing features because there are better solutions is one thing, although it has been done at kernel tree changes for a decade. Removing features for reasons of religion is rather a case of developers removing a useful and unbroken feature for which there is no replacement purely because someone doesn't like it, or it saves a dozen lines of code.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: RFC: Starting a stable kernel series off the 2.6 kernel
In reply to Adrian BunkQuoted 85 lines · Adrian Bunk
The current kernel development model is pretty good for people who always want to use or offer their costumers the maximum amount of the latest bugs^Wfeatures without having to resort on additional patches for them.
Problems of the current development model from a user's point of view are:
- many regressions in every new release
- kernel updates often require updates for the kernel-related userspace
(e.g. for udev or the pcmcia tools switch)One problem following from this is that people continue to use older kernels with known security holes because the amount of work for kernel upgrades is too high.
These problems follow from the development model.
The latest stable kernel series without these problems is 2.4, but 2.4 is becoming more and more obsolete and might e.g. lack driver support for some recent hardware you want to use.
Since Andrew and Linus do AFAIK not plan to change the development model, what about the following for getting a stable kernel series without leaving the current development model:
Kernel 2.6.16 will be the base for a stable series.
After 2.6.16, there will be a 2.6.16.y series with the usual stable rules.
After the release of 2.6.17, this 2.6.16.y series will be continued with more relaxed rules similar to the rules in kernel 2.4 since the release of kernel 2.6.0 (e.g. driver updates will be allowed).
Q:
What is the target audience for this 2.6.16 series?A:
The target audience are users still using 2.4 (or who'd still use kernel 2.4 if they weren't forced to upgrade to 2.6 for some reason) who want a stable kernel series including security fixes but excluding many regressions.
It might also be interesting for distributions that prefer stability over always using the latest stuff.Q:
Does this proposal imply anything for the development between 2.6.15 and 2.6.16?A:
In theory not.
In practice, it would be a big advantage if some of the bigger changes that might go into 2.6.16 would be postponed to 2.6.17.Q:
Why not start with the more relaxed rules before the release of 2.6.17?A:
After 2.6.16.y following the usual stable rules, the kernel should be relatively stable and well-tested giving the best possible basis for a long-living series.Q:
How long should this 2.6.16 series be maintained?A:
Time will tell, but if people use it I'd expect 2 or 3 years.Q:
Stable API/ABI for external modules?A:
No.Q:
Who will maintain this branch?
Quoted 8 lines
A:
I could do it, but if someone more experienced wants to do it that would be even better.
-
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/
What if ...
1. When people make a patch set, if they have encountered any 'bugs' they split them out as separate items.
2. The submitter would identify through GIT when the error had been introduced so that the the person responsible could be CC'ed, also anybody who had worked on the code recently would be CCed, therefore the programmers who were most familiar with that section of code would be made aware of it.
3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the subject line. In the body of the fix would be noted each kernel to which the
fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX 2.6.14]
4. The programmers mentioned in (2) would ACK the patch which would then become part of an 'official' fixes list.
5. If a volunteer wanted to maintain, say, 2.6.14 + fixes, they could build and test it and be a point of contact regarding any problems. These could hopefully be tracked down and submitted as a new fix patch.
regards,
Felix
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Felix Oxley <[email protected]> wrote:
[...]
Quoted 4 lines
What if ...
1. When people make a patch set, if they have encountered any 'bugs' they split them out as separate items.
No need. Patches are either (a) bug fixes, or (b) infrastructure changes, or (c) additions (mostly drivers). You only need to pick (a) items. Check.
Quoted 2 lines
2. The submitter would identify through GIT when the error had been introduced
Hard to find out. Nobody will do so.
Quoted 4 lines
so that the the person responsible could be CC'ed, also
anybody who had worked on the code recently would be CCed, therefore the programmers who were most familiar with that section of code would be made aware of it.
Cc:ing them is part of the development anyway (in reality, Cc:ing anybody interested in the area). Check.
Quoted 4 lines
3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the subject line.
In the body of the fix would be noted each kernel to which the fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX 2.6.14]
No do. Problem are the (b) and (c) patches above, they change whatever the patch applies to and make it not apply anymore. The effort of finding out if the patch is (a) or (c) class, seeing if it is really needed, and modifying it so it applies to your source base is called "backporting". And it remains hard, thankless work.
Quoted 2 lines
4. The programmers mentioned in (2) would ACK the patch which would then become part of an 'official' fixes list.
Won't happen.
Quoted 3 lines
5. If a volunteer wanted to maintain, say, 2.6.14 + fixes, they could build and test it and be a point of contact regarding any problems. These could hopefully be tracked down and submitted as a new fix patch.
Go right ahead. Just be warned that distributions hired a small army of kernel specialists to do exactly this, and got tired of doing so. Among others because the patches deemed necessary were different from one distributuion to the next, and then usually incompatible with one another and with what turned out to be the standard solution. This gave rise to the current development model...
Armchair software engineering is much like armchair $SPORT.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 30 lines · Horst von Brand
Felix Oxley <[email protected]> wrote:
[...]
Quoted 4 lines
What if ...
1. When people make a patch set, if they have encountered any 'bugs' they split them out as separate items.
No need. Patches are either (a) bug fixes, or (b) infrastructure changes, or (c) additions (mostly drivers). You only need to pick (a) items. Check.
Quoted 2 lines
2. The submitter would identify through GIT when the error had been introduced
Hard to find out. Nobody will do so.
Quoted 4 lines
so that the the person responsible could be CC'ed, also
anybody who had worked on the code recently would be CCed, therefore the programmers who were most familiar with that section of code would be made aware of it.Cc:ing them is part of the development anyway (in reality, Cc:ing anybody interested in the area). Check.
Quoted 4 lines
3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the subject line.
In the body of the fix would be noted each kernel to which the fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX 2.6.14]
Quoted 5 lines
No do. Problem are the (b) and (c) patches above, they change whatever the patch applies to and make it not apply anymore. The effort of finding out if the patch is (a) or (c) class, seeing if it is really needed, and modifying it so it applies to your source base is called "backporting". And it remains hard, thankless work.
If this was done for 'trivial' patches of type (a):
1. Would that make it simple enough for people to actually do it?
2. Would it be worthwhile? (Are there enough 'trivial fixes'?)
I envisaged something like the current Stable series, just for longer than a single release cycle.
Quoted 9 lines
Quoted 2 lines
4. The programmers mentioned in (2) would ACK the patch which would then become part of an 'official' fixes list.
Won't happen.
Quoted 3 lines
5. If a volunteer wanted to maintain, say, 2.6.14 + fixes, they could build and test it and be a point of contact regarding any problems. These could hopefully be tracked down and submitted as a new fix patch.
Quoted 8 lines
Go right ahead. Just be warned that distributions hired a small army of kernel specialists to do exactly this, and got tired of doing so. Among others because the patches deemed necessary were different from one distributuion to the next, and then usually incompatible with one another and with what turned out to be the standard solution. This gave rise to the current development model...
Armchair software engineering is much like armchair $SPORT.
I am guilty :-)
Thanks for your reply.
regards,
Felix
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 13 lines · Felix Oxley
Quoted 12 lines · Horst von Brand
Felix Oxley <[email protected]> wrote:
[...]
Quoted 4 lines
What if ...
1. When people make a patch set, if they have encountered any 'bugs' they split them out as separate items.
No need. Patches are either (a) bug fixes, or (b) infrastructure changes, or (c) additions (mostly drivers). You only need to pick (a) items. Check.
[...]
Quoted 11 lines
Quoted 10 lines
Quoted 4 lines
3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the subject line.
In the body of the fix would be noted each kernel to which the fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX 2.6.14]No do. Problem are the (b) and (c) patches above, they change whatever the patch applies to and make it not apply anymore. The effort of finding out if the patch is (a) or (c) class, seeing if it is really needed, and modifying it so it applies to your source base is called "backporting". And it remains hard, thankless work.
Quoted 3 lines
If this was done for 'trivial' patches of type (a):
1. Would that make it simple enough for people to actually do it?
2. Would it be worthwhile? (Are there enough 'trivial fixes'?)
Not all important fixes are "trivial", far from it; so this is rather suspect in any case. Changes to the underlying source make even "trivial" patches soon not apply anymore. And there still is the job of finding out if some patch is or is not necessary...
Quoted 2 lines
I envisaged something like the current Stable series, just for longer than a single release cycle.
Go right ahead. If enough people get interested and work on it, it might turn out useful. I rather doubt it, as the current development model is exactly geared towards keeping people up to date, not running ancient kernels and then jumping a few versions ahead. The problem with doing that is that instead of one problem at a time you see a dozen, and then it is hard to pin down /when/ it broke (and thus what change is responsible). Plus the drift from backported patches, where you can't be sure it /seemed/ to work because of some random patch.
Again, this development model was tried /hard/ for some 12 years by the distributions, and found sorely lacking (and essentially unfixable).
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Re: RFC: Starting a stable kernel series off the 2.6 kernel
Quoted 50 lines · Horst von Brand
Quoted 13 lines · Felix Oxley
Quoted 12 lines · Horst von Brand
Felix Oxley <[email protected]> wrote:
[...]
Quoted 4 lines
What if ...
1. When people make a patch set, if they have encountered any 'bugs' they split them out as separate items.
No need. Patches are either (a) bug fixes, or (b) infrastructure changes, or (c) additions (mostly drivers). You only need to pick (a) items. Check.
[...]
Quoted 12 lines
Quoted 11 lines
Quoted 5 lines
3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the subject line.
In the body of the fix would be noted each kernel to which the fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX
2.6.14]No do. Problem are the (b) and (c) patches above, they change whatever the patch applies to and make it not apply anymore. The effort of finding out if the patch is (a) or (c) class, seeing if it is really needed, and modifying it so it applies to your source base is called "backporting". And it remains hard, thankless work.
Quoted 3 lines
If this was done for 'trivial' patches of type (a):
1. Would that make it simple enough for people to actually do it?
2. Would it be worthwhile? (Are there enough 'trivial fixes'?)Not all important fixes are "trivial", far from it; so this is rather suspect in any case. Changes to the underlying source make even "trivial" patches soon not apply anymore. And there still is the job of finding out if some patch is or is not necessary...
Quoted 2 lines
I envisaged something like the current Stable series, just for longer than a single release cycle.
Go right ahead. If enough people get interested and work on it, it might turn out useful. I rather doubt it, as the current development model is exactly geared towards keeping people up to date, not running ancient kernels and then jumping a few versions ahead. The problem with doing that is that instead of one problem at a time you see a dozen, and then it is hard to pin down /when/ it broke (and thus what change is responsible). Plus the drift from backported patches, where you can't be sure it /seemed/ to work because of some random patch.
Quoted 2 lines
Again, this development model was tried /hard/ for some 12 years by the distributions, and found sorely lacking (and essentially unfixable).
Thank you for your explanation.
I will retire to lurk quietly in my armchair. :-)
regards,
Felix