New dev model (was [PATCH] delete devfs)

New dev model (was [PATCH] delete devfs)

[Jonathan Corbet]

> Ok, is there anywhere else that isn't subscriber-only that has the scoop?

For those who weren't here, the basic scoop is this:

- 2.6 is doing great, despite the fact that (by Andrew's reckoning) some
  10mb/month of patches are going into it.

- Linus is majorly pleased with how the partnership with Andrew has been
  working, and few people feel that he shouldn't be.  He is a little
  concerned about breaking a highly effective process when 2.7 forks.

- There is not a whole lot of pressure to create a 2.7 now, but a lot of
  interest in getting patches into the mainstream quickly.

The end result is that there may not be a 2.7 for a while.  Instead,
significant patches will continue to go into 2.6, after a vetting period
in -mm.  Andrew stated his willingness to consider, for example,
four-level page tables, MODULE_PARM removal, API changes, and more.  2.7
will only be created when it becomes clear that there are sufficient
patches which are truly disruptive enough to require it.  When 2.7 *is*
created, it could be highly experimental, and may turn out to be a
throwaway tree.

Andrew's vision, as expressed at the summit, is that the mainline kernel
will be the fastest and most feature-rich kernel around, but not,
necessarily, the most stable.  Final stabilization is to be done by
distributors (as happens now, really), but the distributors are expected
to merge their patches quickly.

Anybody disagree with that summary?

jon

Jonathan Corbet
Executive editor, LWN.net
corbet@lwn.net

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Wed, Jul 21, 2004 at 05:11:23PM -0600, Jonathan Corbet wrote:

> > Ok, is there anywhere else that isn't subscriber-only that has the scoop?
> 
> For those who weren't here, the basic scoop is this:
> 
> - 2.6 is doing great, despite the fact that (by Andrew's reckoning) some
>   10mb/month of patches are going into it.
> 
> - Linus is majorly pleased with how the partnership with Andrew has been
>   working, and few people feel that he shouldn't be.  He is a little
>   concerned about breaking a highly effective process when 2.7 forks.
> 
> - There is not a whole lot of pressure to create a 2.7 now, but a lot of
>   interest in getting patches into the mainstream quickly.
> 
> The end result is that there may not be a 2.7 for a while.  Instead,
> significant patches will continue to go into 2.6, after a vetting period
> in -mm.  Andrew stated his willingness to consider, for example,
> four-level page tables, MODULE_PARM removal, API changes, and more.  2.7
> will only be created when it becomes clear that there are sufficient
> patches which are truly disruptive enough to require it.  When 2.7 *is*
> created, it could be highly experimental, and may turn out to be a
> throwaway tree.
> 
> Andrew's vision, as expressed at the summit, is that the mainline kernel
> will be the fastest and most feature-rich kernel around, but not,
> necessarily, the most stable.  Final stabilization is to be done by
> distributors (as happens now, really), but the distributors are expected
> to merge their patches quickly.
> 
> Anybody disagree with that summary?

Thanksfor this mail, this is exactly the information that was missing.

Discussing the contents:
Changes that remove functionally like Greg's patch are hopefully 
still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
inside a stable kernel series are a must for many users.

> jon
 
cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Greg KH]

On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > Changes that remove functionally like Greg's patch are hopefully 
> > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> > inside a stable kernel series are a must for many users.
> 
> I don't necessarily agree that such changes in the userspace interface
> should be tied to the kernel version number, really.  That's a three or
> four year warning period, which is unreasonably long.  Six to twelve months
> should be long enough for udev-based replacements to stabilise and
> propagate out into distributions.

Users have had the 6-12 month warning about devfs for a while now :)
And udev is currently available in the latest distro versions of:
	- Red Hat
	- SuSE
	- Gentoo
	- Debian
	- Mandrake

While devfs is only supported in Gentoo at this time (and udev fills
that support issue for those users.)

> That being said, mid-2005 would be an appropriate time to remove devfs.  If
> that schedule pushes things along faster than they would otherwise have
> progressed, well, good.

Ok, if people think that would really change anything, I'll wait a year.
I'm patient :)

thanks,

greg k-h

New dev model (was [PATCH] delete devfs)

[Svetoslav Slavtchev]

Hi,
sorry for the scrumbled reply as i'm not
subscribed to the list.

Mandrake is using devfs as default way to manage
devices ever since it included the 2.4.0-test kernels
and is currently near freeze for the next release 10.1
which will be probably based on 2.6.8 kernel still using
devfs. 
The current state of udev in Mandrake is pretty useless, 
none made attempts to integrate udev as replacement 
of devfs. Yes there is a binary package of udev,
but technically it's as if it's missing. udev
is mostly working, but ....
the entire distro is not aware of it existence
udev is not supported by init scripts, mkinitrd
the distro's tools for configuration

if you really decide to drop devfs so soon,
i guess the only choice for the next Mandrake release
would be to revert the patch or stay with an older kernel

best,

svetljo

-- 
+++ GMX DSL-Tarife 3 Monate gratis* +++ Nur bis 25.7.2004 +++
Bis 24.000 MB oder 300 Freistunden inkl. http://www.gmx.net/de/go/dsl

Re: New dev model (was [PATCH] delete devfs)

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> Changes that remove functionally like Greg's patch are hopefully 
> still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> inside a stable kernel series are a must for many users.

I don't necessarily agree that such changes in the userspace interface
should be tied to the kernel version number, really.  That's a three or
four year warning period, which is unreasonably long.  Six to twelve months
should be long enough for udev-based replacements to stabilise and
propagate out into distributions.

That being said, mid-2005 would be an appropriate time to remove devfs.  If
that schedule pushes things along faster than they would otherwise have
progressed, well, good.


Nothing is cast in stone here btw - we're pushing the envelope, trying new
things, keeping that which works well and reexamining things which perhaps
don't work so well.  Feel free to disagree - we're listening.

Re: New dev model (was [PATCH] delete devfs)

[Andrew Morton]

Greg KH <greg@kroah.com> wrote:
>
> On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> > Adrian Bunk <bunk@fs.tum.de> wrote:
> > >
> > > Changes that remove functionally like Greg's patch are hopefully 
> > > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> > > inside a stable kernel series are a must for many users.
> > 
> > I don't necessarily agree that such changes in the userspace interface
> > should be tied to the kernel version number, really.  That's a three or
> > four year warning period, which is unreasonably long.  Six to twelve months
> > should be long enough for udev-based replacements to stabilise and
> > propagate out into distributions.
> 
> Users have had the 6-12 month warning about devfs for a while now :)

No, they had a three year warning.  "It'll be gone in 2.8".

> Ok, if people think that would really change anything, I'll wait a year.
> I'm patient :)

Delete 100 lines per week ;)

Re: New dev model (was [PATCH] delete devfs)

[Han Boetes]

Svetoslav Slavtchev wrote:
> the entire distro is not aware of it existence udev is not supported by init
> scripts, mkinitrd the distro's tools for configuration

Implementing support for udev is a piece of pie.



# Han

Re: New dev model (was [PATCH] delete devfs)

[Giacomo A. Catenazzi]

Greg KH wrote:

> On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> 
> Users have had the 6-12 month warning about devfs for a while now :)
> And udev is currently available in the latest distro versions of:
> 	- Red Hat
> 	- SuSE
> 	- Gentoo
> 	- Debian
> 	- Mandrake
> 
> While devfs is only supported in Gentoo at this time (and udev fills
> that support issue for those users.)

I've still some bug report of people using home-compiled devfs kernels
on Debian. So people still use it. You say "devfs" is buggy, but
it works on nearly all cases, so people tend not to switch.

The worse is the lack of stable name of devices, in udev too.
I.e. microcode loader (Intel CPU) needs a device, which was so
named (last time I controlled):
   # device name in LANANA / devices.txt
   DEVICE=/dev/cpu/microcode
   # device name in devfsd
   DEVICE2=/dev/misc/microcode
   # device name in udev
   DEVICE3=/dev/microcode

If we a coherent *default* device name scheme, the switching
from a kernel utility to other would be trivial.

ciao
	cate

Note: /dev/cpu/microcode was also created by devfs until
recent 2.4 kernels and the whole 2.6 serie.



> 
> 
>>That being said, mid-2005 would be an appropriate time to remove devfs.  If
>>that schedule pushes things along faster than they would otherwise have
>>progressed, well, good.
> 
> 
> Ok, if people think that would really change anything, I'll wait a year.
> I'm patient :)

Re: New dev model (was [PATCH] delete devfs)

[Josh Boyer]

On Thu, 2004-07-22 at 05:19, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> > > Adrian Bunk <bunk@fs.tum.de> wrote:
> > > >
> > > > Changes that remove functionally like Greg's patch are hopefully 
> > > > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> > > > inside a stable kernel series are a must for many users.
> > > 
> > > I don't necessarily agree that such changes in the userspace interface
> > > should be tied to the kernel version number, really.  That's a three or
> > > four year warning period, which is unreasonably long.  Six to twelve months
> > > should be long enough for udev-based replacements to stabilise and
> > > propagate out into distributions.
> > 
> > Users have had the 6-12 month warning about devfs for a while now :)
> 
> No, they had a three year warning.  "It'll be gone in 2.8".
> 
> > Ok, if people think that would really change anything, I'll wait a year.
> > I'm patient :)
> 
> Delete 100 lines per week ;)

That could be done by sending in smaller patches that remove devfs calls
from drivers.  If nothing in the kernel is using devfs, then there is no
reason to keep it around anymore...

Just a thought.

josh

Re: New dev model (was [PATCH] delete devfs)

[Svetoslav Slavtchev]

once again, sorry for this way of replying,
could you keep me CC'd as i'm not subscribed to lkml

-----------start of original message --------------
On Thu, 2004-07-22 at 05:19, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> > > Adrian Bunk <bunk@fs.tum.de> wrote:
> > > >
> > > > Changes that remove functionally like Greg's patch are hopefully 
> > > > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> > > > inside a stable kernel series are a must for many users.
> > > 
> > > I don't necessarily agree that such changes in the userspace interface
> > > should be tied to the kernel version number, really.  That's a three
or
> > > four year warning period, which is unreasonably long.  Six to twelve
months
> > > should be long enough for udev-based replacements to stabilise and
> > > propagate out into distributions.
> > 
> > Users have had the 6-12 month warning about devfs for a while now :)
> 
> No, they had a three year warning.  "It'll be gone in 2.8".
> 
> > Ok, if people think that would really change anything, I'll wait a year.
> > I'm patient :)
> 
> Delete 100 lines per week ;)

That could be done by sending in smaller patches that remove devfs calls
from drivers.  If nothing in the kernel is using devfs, then there is no
reason to keep it around anymore...

Just a thought.

josh

-----------end of original message --------------

please don't do it /*at least not in the following two months :-)*/

what does this buy us ?

once again about the upcoming Mandrake 10.1,
we already have readded devfs support to isdn,
should we start tracking bk-head for such patches
that remove devfs support from drivers
and revert them ? 
should we stay with 2.6.7 (or eventually 2.6.8)?
there is really no time to integarate/test udev
as replacement of devfs for the next release.

best,

svetljo

-- 
+++ GMX DSL-Tarife 3 Monate gratis* +++ Nur bis 25.7.2004 +++
Bis 24.000 MB oder 300 Freistunden inkl. http://www.gmx.net/de/go/dsl

Re: New dev model (was [PATCH] delete devfs)

[Greg KH]

On Thu, Jul 22, 2004 at 01:32:13PM +0200, Giacomo A. Catenazzi wrote:
> 
> The worse is the lack of stable name of devices, in udev too.
> I.e. microcode loader (Intel CPU) needs a device, which was so
> named (last time I controlled):

When was the last time you _used_ the microcode device?

Yeah, there are still a small number of drivers that are not in sysfs,
so udev doesn't know about them, but right now I'm guessing we cover
about 95%.  I'm waiting for someone else to fix up the rest, if they
really have one of those odd devices :)

thanks,

greg k-h

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

Hi Andrew,

my personal opinon is that this new development model isn't a good 
idea from the point of view of users:

There's much worth in having a very stable kernel. Many people use for 
different reasons self-compiled ftp.kernel.org kernels. In 2.4, it took 
until at about 2.4.18 or 2.4.22 [1] until it was reasonable stable. 
Today, most code in the 2.4 kernel has had several years of testing and 
it's therefore quite stable even in unusual configurations. Besides 
this, an upgrade like from 2.4.25 to 2.4.26 is pretty low-risk since  
there shouldn't be any changes that might break existing setups.

If your work together with Linus is so effective, why can't you both do 
all the changes in a new 2.7 tree that includes also all incompatible 
and potential dangerous changes as well as the removal of obsolete code 
like devfs or OSS. I don't see the negative effect if a 2.7 branch was 
created today and together with a feature freeze for 2.7 three months  
from now this might result in a 2.8.0 before christmas [2] that contains 
all the new features/removals/changes while 2.6 will evolve further into 
a rock-solid stable kernel.

cu
Adrian

[1] there are different opinions on the exact version number, but it was
    definitely not 2.4.10
[2] perhaps a bit optimistic, but it shouldn't be years from now

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Thu, Jul 22, 2004 at 04:01:12PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > my personal opinon is that this new development model isn't a good 
> > idea from the point of view of users:
> > 
> > There's much worth in having a very stable kernel. Many people use for 
> > different reasons self-compiled ftp.kernel.org kernels. 
> 
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.

4kb stacks were added after 2.6.0 and now 4KSTACKS=y results in Oops'es 
under some circumstances if using XFS.

2.6 currently still becomes stabler, but every new/changed feature bears 
the risk of breaking something.

> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.

Who will maintain the many subtrees of 2.6 this implies?

Even after 2.6.20 was already released, you might have to release a 
2.6.19.5 with a few additional security fixes since according to your 
advice users should continue to use 2.6.19 for a few weeks which 
implies that someone will have to maintain at least the 2.6.19 tree for 
at least a few weeks after the release of 2.6.20 .

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Kevin Fox]

How is this any different then the old dev model with very short release
cycles? (Other then keeping a "2." prefixed forever)

On Thu, 2004-07-22 at 16:01, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > my personal opinon is that this new development model isn't a good 
> > idea from the point of view of users:
> > 
> > There's much worth in having a very stable kernel. Many people use for 
> > different reasons self-compiled ftp.kernel.org kernels. 
> 
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.
> 
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: New dev model (was [PATCH] delete devfs)

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Fri, 2004-07-23 at 01:01, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > my personal opinon is that this new development model isn't a good 
> > idea from the point of view of users:
> > 
> > There's much worth in having a very stable kernel. Many people use for 
> > different reasons self-compiled ftp.kernel.org kernels. 
> 
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.
> 
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.

I wont recommend this, as it screws with some (most?) things trying
to detect kernel version running from uname =)


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: New dev model (was [PATCH] delete devfs)

[Paul Jackson]

> There's much worth in having a very stable kernel.

There certainly is.  But the contribution that having a separate 2.7/2.8
kernel at the head (Linus, et. al.) end has to a user having a stable kernel
is not what you think it is.

The direction presented to us now is having smaller, more continuous,
steps in the head end, over having fewer larger, more disruptive steps. 
Do we do all the incompatible changes in a big chunk, once every couple
of years, or do we do them one a week, ongoing.

Now, I repeat, this is at the head end.  End users who want stability
aren't feeding directly off kernel.org anyway.

The affect downstream on real users is this.  If the head end operates
in big chunky style, then as this big change flows downstream, it makes
transitions for distros, service providers and middlemen more costly and
difficult, creating expenses that must be passed on to the end user.

Yes - damming up the flow of changes creates stability.  But if you're a
middleman, you don't need Linus to choose where to build the dam, and
when to open the flood gates.  It's more efficient for you to choose for
yourself when to do that damming, based on your particular resources and
customer needs, rather than have to deal with hundred year floods and
draughts imposed on you by Zeus.

The end user always gets their stability, if only because they won't
upgrade a system that is "working".

And every change at the head end is disruptive for some poor slob.
The only perfectly compatible change is no change at all.  We delude
ourselves if we think we can separate the "safe" fixes and additions
from the "unsafe" incompatible changes.  Better that we should expend
some energy on smoothing out and minimizing the cost of change to those
downstream from us.  This needs to be done the old-fashioned way, one
change at a time.

The question is whether we impose, on all those downstream from us,
occasional hundred year floods, or do we provide a steady stream, and
let them build their own little beaver dams, as suits their various and
diverse needs and business cycles.

The great lesson of capitalism over communism is that a thousand free
workers and investors, each optimizing their own little plot or
portfolio, beats a single centrally imposed five year plan, even if the
man pulling the levers is a genius such as Linus or Lenin (sorry, Linus,
couldn't resist ...).

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: New dev model (was [PATCH] delete devfs)

[Andrew Morton]

Adrian Bunk <bunk@fs.tum.de> wrote:
>
> my personal opinon is that this new development model isn't a good 
> idea from the point of view of users:
> 
> There's much worth in having a very stable kernel. Many people use for 
> different reasons self-compiled ftp.kernel.org kernels. 

Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
adding features.

I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
fixes against 2.6.20 if there is demand for it.  Anyone who really cares
about stability of kernel.org kernels won't be deploying 2.6.20 within a
few weeks of its release anyway, so by the time they doodle over to
kernel.org they'll find 2.6.20.2 or whatever.

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Thu, Jul 22, 2004 at 03:28:39PM -0700, Paul Jackson wrote:

> > There's much worth in having a very stable kernel.
>...
> Now, I repeat, this is at the head end.  End users who want stability
> aren't feeding directly off kernel.org anyway.

It depend on your definition of "end users" and "stability".

You might be right for people buying for many $$$ distributions with 
support to run Oracle on it.

But I know many people who run ftp.kernel.org kernels on many 
workstations and small servers e.g. in universities.

> The affect downstream on real users is this.  If the head end operates
> in big chunky style, then as this big change flows downstream, it makes
> transitions for distros, service providers and middlemen more costly and
> difficult, creating expenses that must be passed on to the end user.

Currently there's one transition to a new major release of the kernel 
every few years. You wait until a new major release of the kernel has 
matured, test whether both the transition and the new kernel work, and 
update the kernel.

An update to a new minor version of the kernel was until now relatively 
cheep since breakages that require further investigation were relatively 
seldom.

And what happens if you are a distribution, kernel 2.6.15 is the current 
kernel containing many important updates, but $nontrivial_feature added 
in 2.6.10 broke $architecture your distribution supports. This means you 
have to support both kernel versions with security updates creating  
expenses that must be passed on to the end user.

I vaguely remember such issues in the past like DECstation support 
was broken since 2.4.20, and some m68k subarchs that were at least until 
recently not working in any kernel more recent than 2.2 .

Such breakages might occur more often in the future during a stable 
series.

> Yes - damming up the flow of changes creates stability.  But if you're a
> middleman, you don't need Linus to choose where to build the dam, and
> when to open the flood gates.  It's more efficient for you to choose for
> yourself when to do that damming, based on your particular resources and
> customer needs, rather than have to deal with hundred year floods and
> draughts imposed on you by Zeus.
> 
> The end user always gets their stability, if only because they won't
> upgrade a system that is "working".

How do such end users get security updates?

> And every change at the head end is disruptive for some poor slob.
> The only perfectly compatible change is no change at all.  We delude
> ourselves if we think we can separate the "safe" fixes and additions
> from the "unsafe" incompatible changes.  Better that we should expend
> some energy on smoothing out and minimizing the cost of change to those
> downstream from us.  This needs to be done the old-fashioned way, one
> change at a time.
> 
> The question is whether we impose, on all those downstream from us,
> occasional hundred year floods, or do we provide a steady stream, and
> let them build their own little beaver dams, as suits their various and
> diverse needs and business cycles.
>...

But what to do if some part of the kernel (let's call it "XFS") has some 
problems (let's call it "Oops") with a new feature (let's call it "4kb 
stacks on i386") introduced in a kernel during a stable kernel series 
(let's call it "2.6.6") and this isn't fixed by the maintainers (let's  
call them "SGI") for some time (let's call it "until now")?

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Jason Cooper]

Andrew Morton (akpm@osdl.org) scribbled:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> > There's much worth in having a very stable kernel. Many people use for 
> > different reasons self-compiled ftp.kernel.org kernels. 

I have to agree with Adrian, the first thing I always do with a new
distro is rip out the kernel and drop in a vanilla from kernel.org.
I've been biten too many times by distro kernels. :(

> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.

imho, I feel there are two main concerns with changing the development
model:

	1.) Need to have readily identifiable stable versions w/o
	    following lkml.
	2.) Understanding the changing of version numbers in light of
	    this change of strategy.

Ideas:

wrt (1), I think the -rc? system would be simplest.  2.6.20 is stable,
2.6.20-rc3 is not.  

wrt (2), assuming the naming stays the same:

	major++ = major overhaul of core system.
	minor++ = overhaul to drivers (or subset thereof).
	patch++ = testing patches survived, appear stable.
	extra++ = next set of testing patches applied.

Sure, this would mean version numbers start to creap up, but nothing is
stopping a kernel version 2.11.x (what?! where's my 3.0.1?  We were
definitely supposed to have a 3.0 around here somewhere... Where's my
meds? *frowns*).

tia,

Cooper.

Re: New dev model (was [PATCH] delete devfs)

[Tim Wright]

On Thu, 2004-07-22 at 16:25, Adrian Bunk wrote:
> On Thu, Jul 22, 2004 at 03:28:39PM -0700, Paul Jackson wrote:
> 
> > > There's much worth in having a very stable kernel.
> >...
> > Now, I repeat, this is at the head end.  End users who want stability
> > aren't feeding directly off kernel.org anyway.
> 
> It depend on your definition of "end users" and "stability".
> 
> You might be right for people buying for many $$$ distributions with 
> support to run Oracle on it.
> 
> But I know many people who run ftp.kernel.org kernels on many 
> workstations and small servers e.g. in universities.
> 

That is their choice, but there's no particular need to run a kernel.org
kernel. Unless you're messing around with the kernel or have a hot
requirement for some new feature, why would running a stable kernel from
e.g. Debian not suffice? Debian is free and freely available, and it's
not the only distribution that is that way.

You can't have it both ways. If all you care about is stability, you can
run Debian stable, and be rock solid. If you want to play with the
latest code, you can download a kernel.org kernel. There is no shortage
of sources of kernels. It would simply mean that the kernel.org one
would have slightly less of a guarantee to be "stable", although as was
originally reported, 2.6 is going very well, and despite the flow of
changes, there isn't a lot of terrible breakage happening.

[...]

> 
> And what happens if you are a distribution, kernel 2.6.15 is the current 
> kernel containing many important updates, but $nontrivial_feature added 
> in 2.6.10 broke $architecture your distribution supports. This means you 
> have to support both kernel versions with security updates creating  
> expenses that must be passed on to the end user.
> 

No, you have several choices. For instance, you can continue to ship
2.6.10, or you can fix the problem. The reason Red Hat shipped a
different gcc back in the 7.x days and were subjected to much flamage
was because they wanted a c++ compiler that worked on architectures
other than x86 (alpha), and they put in effort to obtain such. Using Red
Hat as an example again, RHEL3 is based on 2.4.21. The current update is
still labelled as 2.4.21. It has fixes from later kernels but it isn't
based on 2.4.26. So this doesn't involve a radical change from how
things are today. They backport security fixes as do pretty much all
distros.

[...]

> 
> > Yes - damming up the flow of changes creates stability.  But if you're a
> > middleman, you don't need Linus to choose where to build the dam, and
> > when to open the flood gates.  It's more efficient for you to choose for
> > yourself when to do that damming, based on your particular resources and
> > customer needs, rather than have to deal with hundred year floods and
> > draughts imposed on you by Zeus.
> > 
> > The end user always gets their stability, if only because they won't
> > upgrade a system that is "working".
> 
> How do such end users get security updates?
> 

>From the middleman. That's no different to users of any distros today.
The distros apply security fixes and make updated kernels available on a
regular basis.

> > And every change at the head end is disruptive for some poor slob.
> > The only perfectly compatible change is no change at all.  We delude
> > ourselves if we think we can separate the "safe" fixes and additions
> > from the "unsafe" incompatible changes.  Better that we should expend
> > some energy on smoothing out and minimizing the cost of change to those
> > downstream from us.  This needs to be done the old-fashioned way, one
> > change at a time.
> > 
> > The question is whether we impose, on all those downstream from us,
> > occasional hundred year floods, or do we provide a steady stream, and
> > let them build their own little beaver dams, as suits their various and
> > diverse needs and business cycles.
> >...
> 
> But what to do if some part of the kernel (let's call it "XFS") has some 
> problems (let's call it "Oops") with a new feature (let's call it "4kb 
> stacks on i386") introduced in a kernel during a stable kernel series 
> (let's call it "2.6.6") and this isn't fixed by the maintainers (let's  
> call them "SGI") for some time (let's call it "until now")?
> 

Umm... compile the kernel with 8k stacks? Nobody is forcing you to use
the new option. And as has been pointed out by Chris, you are still at
risk of a stack overflow even with the 8k stacks if you take an
interrupt at the wrong time and it happens to be a heavy stack user. Or
you could run 2.4.26. Or...

The reasoning is that the advantages are heavily outweighing the
disadvantages, and I have to agree.

Regards,

Tim

-- 
Tim Wright <timw@splhi.com>
Splhi

Re: New dev model (was [PATCH] delete devfs)

[Ville Herva]

On Thu, Jul 22, 2004 at 07:22:10PM -0700, you [Tim Wright] wrote:
> > 
> > How do such end users get security updates?
> 
> From the middleman. That's no different to users of any distros today.
> The distros apply security fixes and make updated kernels available on a
> regular basis.

One idea might be to fork off "stable" 2.6.x.y (2.6.15.1 for example)
branches every now and them. Analogous to vendor kernels, but maintained by
someone@kernel.org. Compared to the 2.6.x.0 in question, these would only
get security fixes and important bug fixes. The maintainer would need to
pick a suitable (stable) 2.6.x.0 as basis every once in an appropriate
while.

I don't know if that's feasible. Just an idea.

Anyway, as (one kind of) end user, I do welcome the new development model.
I'll get the newest features in manageable manner, and if I don't fancy that
I can resort to vendor (Fedora) kernels.


-- v -- 

v@iki.fi

Re: New dev model (was [PATCH] delete devfs)

[szonyi calin]

--- Paul Jackson <pj@sgi.com> a écrit : > > There's much worth
in having a very stable kernel.
> 
> There certainly is.  But the contribution that having a
> separate 2.7/2.8
> kernel at the head (Linus, et. al.) end has to a user having a
> stable kernel
> is not what you think it is.
> 

;-)

> The direction presented to us now is having smaller, more
> continuous,
> steps in the head end, over having fewer larger, more
> disruptive steps. 
> Do we do all the incompatible changes in a big chunk, once
> every couple
> of years, or do we do them one a week, ongoing.
> 
... and break existing compatibility, and make the system crash 
twice a day ...

> Now, I repeat, this is at the head end.  End users who want
> stability
> aren't feeding directly off kernel.org anyway.
> 

Are you sure ? There are a number of distribution who use the
 stable kernel from kernel.org and some of them are much faster
(if you remember, compiling a kernel to suit your needs
 sometimes improve performance). 
One size _does not_ fit all.

> The affect downstream on real users is this.  If the head end
> operates
> in big chunky style, then as this big change flows downstream,
> it makes
> transitions for distros, service providers and middlemen more
> costly and
> difficult, creating expenses that must be passed on to the end
> user.
> 

And with new devepment model this expenses will be passed to the

end user when the kernel will not be stable enough and will
 crash. Do you you remember the 8k vs 4k stack problem for 
Nvidia binary kernel module ?

> Yes - damming up the flow of changes creates stability.  But
> if you're a
> middleman, you don't need Linus to choose where to build the
> dam, and
> when to open the flood gates.  It's more efficient for you to
> choose for
> yourself when to do that damming, based on your particular
> resources and
> customer needs, rather than have to deal with hundred year
> floods and
> draughts imposed on you by Zeus.
> 

So now the world is divided in gods (i.e distributions) and we,
mere mortals who should pray to the gods to give us a stable
 kernel ? And if we commit a sin our  machine will crash ? 

> The end user always gets their stability, if only because they
> won't
> upgrade a system that is "working".
> 

They will get the stability through the new discovered 
remote security hole because they don't upgrade their system 
because "the system is working" and they don't need to upgrade ?

> And every change at the head end is disruptive for some poor
> slob.
> The only perfectly compatible change is no change at all.  We
> delude
> ourselves if we think we can separate the "safe" fixes and
> additions
> from the "unsafe" incompatible changes.  Better that we should
> expend
> some energy on smoothing out and minimizing the cost of change
> to those
> downstream from us.  This needs to be done the old-fashioned
> way, one
> change at a time.
> 
> The question is whether we impose, on all those downstream
> from us,
> occasional hundred year floods, or do we provide a steady
> stream, and
> let them build their own little beaver dams, as suits their
> various and
> diverse needs and business cycles.
> 
> The great lesson of capitalism over communism is that a
> thousand free
> workers and investors, each optimizing their own little plot
> or
> portfolio, beats a single centrally imposed five year plan,
> even if the
> man pulling the levers is a genius such as Linus or Lenin
> (sorry, Linus,
> couldn't resist ...).
> 

You are wrong here. You never saw the two systems working.
In comunism: One size fits all. This size is made to accomodate
 80% of the population. 
In capitalism: There are two sizes: one for rich and one for 
the poor. The one for the poor is almost bullshit but is 
cheap and anybody can afford it and the one for the rich
is verry expensive and only few can afford it.
Now do a  s/poor/kernel.org kernel/ and s/rich/distribution
kernels/ and you see what your development model is.

  

=====
--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

Re: New dev model (was [PATCH] delete devfs)

[Jonathan Corbet]

> So now the world is divided in gods (i.e distributions) and we,
> mere mortals who should pray to the gods to give us a stable
>  kernel ?

This seems to be where a lot of the misunderstanding is.  Did anybody
notice just how divergent the distributors' 2.4 (and prior) kernels were
from the mainline?  If you wanted a kernel with that level of features
and stability, you had to get it from them - or apply hundreds of
patches yourself.

One of the goals of the process now is to get those distributor patches
into the mainline quickly.  My expectation is that the mainline kernel
will be far closer to what the distributors ship than it has been in a
long time, and the mainline will be more stable for it.  Just the
opposite of what a lot of people are saying.

jon

Re: New dev model (was [PATCH] delete devfs)

[Geert Uytterhoeven]

On Fri, 23 Jul 2004, [iso-8859-1] szonyi calin wrote:
> And with new devepment model this expenses will be passed to the
> end user when the kernel will not be stable enough and will
>  crash. Do you you remember the 8k vs 4k stack problem for
> Nvidia binary kernel module ?

You want a stable kernel, but you also want to rely on binary-only kernel
modules?

The Linux kernel people cannot guarantee stability with binary-only kernel
modules. And the Linux kernel people cannot solve that problem...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: New dev model (was [PATCH] delete devfs)

[szonyi calin]

--- Geert Uytterhoeven <geert@linux-m68k.org> a écrit : > On
Fri, 23 Jul 2004, [iso-8859-1] szonyi calin wrote:
> > And with new devepment model this expenses will be passed to
> the
> > end user when the kernel will not be stable enough and will
> >  crash. Do you you remember the 8k vs 4k stack problem for
> > Nvidia binary kernel module ?
> 
> You want a stable kernel, but you also want to rely on
> binary-only kernel
> modules?
> 

No. I wasn't clear on that one. My example was wrong. AFAIK the
8k/4k stack kernel problem were causing problems for other 
people too.

> The Linux kernel people cannot guarantee stability with
> binary-only kernel
> modules. And the Linux kernel people cannot solve that
> problem...
> 

I underestand that. 
However hpa told me that the stability of the 2.6 kernel will 
not suffer.

> Gr{oetje,eeting}s,
> 
> 						Geert
> 

Calin

=====
--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Fri, Jul 23, 2004 at 06:21:27AM -0600, Jonathan Corbet wrote:
> > So now the world is divided in gods (i.e distributions) and we,
> > mere mortals who should pray to the gods to give us a stable
> >  kernel ?
> 
> This seems to be where a lot of the misunderstanding is.  Did anybody
> notice just how divergent the distributors' 2.4 (and prior) kernels were
> from the mainline?  If you wanted a kernel with that level of features
> and stability, you had to get it from them - or apply hundreds of
> patches yourself.

The 2.4.18 kernel source in Debian stable in has at about 300kB patches 
applied (gzip'ed 60kB), and many of them fix security bugs that were 
reported since 2.4.18 was released.

> One of the goals of the process now is to get those distributor patches
> into the mainline quickly.  My expectation is that the mainline kernel
> will be far closer to what the distributors ship than it has been in a
> long time, and the mainline will be more stable for it.  Just the
> opposite of what a lot of people are saying.

OTOH, distributions might have to ship more kernel versions and provide 
security updates for more kernels if features in newer 2.6 kernels break 
architectures or subarchitectures they support.

> jon

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Thu, Jul 22, 2004 at 01:28:27PM -0700, Kevin Fox wrote:

> How is this any different then the old dev model with very short release
> cycles? (Other then keeping a "2." prefixed forever)

Currently, the old stable tree will be supported for several years even 
after the new stable tree opens (2.0 and 2.2 seem to be quite dead today 
and might even miss several security fixes but 2.4 is still 
well-maintained). If you use a 2.4 kernel today you know that you can 
follow 2.4 for the next year without risking big breakages.

With the new dev model, I assume noone will maintain a 2.6.8 tree for 
several years.

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Timothy Miller]

Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> 
>>my personal opinon is that this new development model isn't a good 
>>idea from the point of view of users:
>>
>>There's much worth in having a very stable kernel. Many people use for 
>>different reasons self-compiled ftp.kernel.org kernels. 
> 
> 
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.
> 
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.


So instead of even minor numbers indicating stability, you have pushed 
two levels down so that higher sub-revision (minorminorminor?) numbers 
indicate increased levels of stability?

Kinda makes sense.

Does that mean that 2.6.21 and 2.6.20.1 are two separate forks of 
2.6.20, one for development, and the other for stability?

How is this fundamentally different from how it was done before with 
odd/even minor numbers?

It's like the details have been changed to give the illusion that 
development will go faster, when in reality, the fundamental approach 
hasn't really changed.

Re: New dev model (was [PATCH] delete devfs)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Fri, 23 Jul 2004 09:31:31 +0300, Ville Herva said:

> Anyway, as (one kind of) end user, I do welcome the new development model.
> I'll get the newest features in manageable manner, and if I don't fancy that
> I can resort to vendor (Fedora) kernels.

You *do* realize that the kernel in the Fedora development tree is actually *ahead*
of the released kernel.org tree, right?

The current kernel-2.6.7-1.494.src.rpm is based on 2.6.8-rc1-bk5, with a bunch of
RedHat/Fedora patches on top of that.

And the 2.6.5-1.358 kernel that shipped in Fedora Core 2 is actually a 2.6.6-rc3-bk3
with patches on top of that.

I think you meant the RHEL series of kernels - current there is 2.4.21-15.0.3.EL,
with backports of security/bug fixes.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: New dev model (was [PATCH] delete devfs)

[Ville Herva]

On Fri, Jul 23, 2004 at 05:04:35PM -0400, you [Valdis.Kletnieks@vt.edu] wrote:
> On Fri, 23 Jul 2004 09:31:31 +0300, Ville Herva said:
> 
> > Anyway, as (one kind of) end user, I do welcome the new development model.
> > I'll get the newest features in manageable manner, and if I don't fancy that
> > I can resort to vendor (Fedora) kernels.
> 
> You *do* realize that the kernel in the Fedora development tree is
> actually *ahead* of the released kernel.org tree, right?
> 
> The current kernel-2.6.7-1.494.src.rpm is based on 2.6.8-rc1-bk5, with a
> bunch of RedHat/Fedora patches on top of that.
> 
> And the 2.6.5-1.358 kernel that shipped in Fedora Core 2 is actually a
> 2.6.6-rc3-bk3 with patches on top of that.
> 
> I think you meant the RHEL series of kernels - current there is
> 2.4.21-15.0.3.EL, with backports of security/bug fixes.

You are absolutely right, Fedora was a bad example. RHEL is better.

Re: New dev model (was [PATCH] delete devfs)

[Marcelo Tosatti]

On Fri, Jul 23, 2004 at 06:21:27AM -0600, Jonathan Corbet wrote:
> > So now the world is divided in gods (i.e distributions) and we,
> > mere mortals who should pray to the gods to give us a stable
> >  kernel ?
> 
> This seems to be where a lot of the misunderstanding is.  Did anybody
> notice just how divergent the distributors' 2.4 (and prior) kernels were
> from the mainline?  If you wanted a kernel with that level of features
> and stability, you had to get it from them - or apply hundreds of
> patches yourself.
> 
> One of the goals of the process now is to get those distributor patches
> into the mainline quickly.  My expectation is that the mainline kernel
> will be far closer to what the distributors ship than it has been in a
> long time, and the mainline will be more stable for it.  Just the
> opposite of what a lot of people are saying.

Well, back in v2.4 "hot-stop", most of the patches merged into distro's kernels 
were not "trustable" enough to be merged into v2.4 mainline, and I had no capability 
of reviewing them myself and make a good enough judgment of whether they should be included
or not.

Another point I had against merging some of those patches was that most of them were 
targeted at "enterprise" users and benefit almost only them (eg finer-grained locking, etc). 

To resume, I prefered to be more "conservative". 

Of course, fortunately Andrew is much more capable of doing judgements on
"trustability" of patches and so forth.

Obviously its a good thing to try to keep the differences between distro's kernels
and mainline kernels small, and Andrew is targetting that. 

Re: New dev model (was [PATCH] delete devfs)

[Ragnar Hojland Espinosa]

On Fri, Jul 23, 2004 at 10:16:37AM +0200, szonyi calin wrote:
> Are you sure ? There are a number of distribution who use the
>  stable kernel from kernel.org and some of them are much faster
> (if you remember, compiling a kernel to suit your needs
>  sometimes improve performance). 
> One size _does not_ fit all.

Right.  Aaaand if I remember correctly you may download the source
for, say, a RHEL kernel for gratis from Redhat (or a whitebox distro)
and make menuconfig it and compile it the same way you do vanilla
kernels.

In fact, a single tree is far better for stable development in general.
Vanilla things that break get spotted sooner, we avoid 2.x.0 the
syndrome, and distro kernels in general may get more eyes from clueful
people that otherwise would ignore them and leave the problems to
less resourceful users.

"Dont Panic" :)
-- 
Ragnar Hojland - Project Manager
Linalco "Specialists in Linux and Free Software"
http://www.linalco.com  Tel: +34-91-4561700

Re: New dev model (was [PATCH] delete devfs)

[Jan Knutar]

> That is their choice, but there's no particular need to run a kernel.org
> kernel. Unless you're messing around with the kernel or have a hot
> requirement for some new feature, why would running a stable kernel from
> e.g. Debian not suffice? Debian is free and freely available, and it's
> not the only distribution that is that way.

In the past, my experience, shared by many users, I'm sure, has been
that distribution kernels generally give you worse performance (IME RH)
and less stability (IME Fedora).

There's an increasing amount of hardware out there in wide-spread use,
which have no drivers in either kernel.org tree or distribution trees. The
fragmentation between the distributions already make it impossible to
get those drivers to compile on anything but the kernel.org tree, unless
the author of the driver is wealthy and has the resources and floorspace
to have a few different machines with different distributions installed,
and the time and resources for creating workarounds and Makefile
trickery for each and every one. I don't mean binary drivers here, as
they are usually backed by some corporation and target the usual
distributions...

Thus, we have a whole generation of users out there who grew up
with the idea that the distribution kernel is just some bloated,
bug-ridden and mostly incompatible monstrosity that is only barely
good for bootstrapping kernel.org kernel before starting to try
compile the drivers for their hardware.

Trying to change this idea is of course difficult, as everyone is
afraid of change. "Will the drivers break next release?", "Will
I have to stay with an old and exploitable kernel sometime
in the future when the drivers no longer compile on anything
but kernel.org X.Y.Z, when distro is X.Y.(Z-3)-secfix42, and kernel.org
is up to X.Y.Z+5?"

It might very well be that pushing out a large portion of the dev
burden to the periphery will be good in the long term for the
development of the kernel, but in short-term, I only see the
fragmentation problem getting worse. I hope I can be
brutally proven absolutely wrong, though. :-)

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Fri, Jul 23, 2004 at 04:57:35PM -0400, Timothy Miller wrote:
> 
> Andrew Morton wrote:
> >Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> >>my personal opinon is that this new development model isn't a good 
> >>idea from the point of view of users:
> >>
> >>There's much worth in having a very stable kernel. Many people use for 
> >>different reasons self-compiled ftp.kernel.org kernels. 
> >
> >
> >Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> >adding features.
> >
> >I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> >fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> >about stability of kernel.org kernels won't be deploying 2.6.20 within a
> >few weeks of its release anyway, so by the time they doodle over to
> >kernel.org they'll find 2.6.20.2 or whatever.
> 
> 
> So instead of even minor numbers indicating stability, you have pushed 
> two levels down so that higher sub-revision (minorminorminor?) numbers 
> indicate increased levels of stability?
> 
> Kinda makes sense.
> 
> Does that mean that 2.6.21 and 2.6.20.1 are two separate forks of 
> 2.6.20, one for development, and the other for stability?
> 
> How is this fundamentally different from how it was done before with 
> odd/even minor numbers?
>...

Kernel 2.4 continues to be actively supported for several years after 
the release of kernel 2.6 .

How long do you assume will kernel 2.6.20 be supported after the release 
of kernel 2.6.21?

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Jesper Juhl]

On Sun, 25 Jul 2004, Jan Knutar wrote:

>> That is their choice, but there's no particular need to run a kernel.org
>> kernel. Unless you're messing around with the kernel or have a hot
>> requirement for some new feature, why would running a stable kernel from
>> e.g. Debian not suffice? Debian is free and freely available, and it's
>> not the only distribution that is that way.
>
> In the past, my experience, shared by many users, I'm sure, has been
> that distribution kernels generally give you worse performance (IME RH)
> and less stability (IME Fedora).
>

I have to agree with you here. My experience is that the vendor kernels 
are usually build to fit a wide variety of systems and include support for 
a huge amount of features since there's always some of their customers 
that need feature X or feature Y, so they include all of them, which leads 
to a kernel that runs slower than it has to and has a bigger potential for 
problems (more features included == more stuff that can blow up in your 
face).

>
[snip]
> Thus, we have a whole generation of users out there who grew up
> with the idea that the distribution kernel is just some bloated,
> bug-ridden and mostly incompatible monstrosity that is only barely
> good for bootstrapping kernel.org kernel before starting to try
> compile the drivers for their hardware.
>
Indeed. That's my personal attitude to vendor kernels, and I know it's 
shared by most of my Linux using friends.
First thing you do after getting your distribution of choice installed is 
to go to kernel.org, grab the latest stable kernel, build it with the 
features you need and then leave the vendor kernel far behind for good. 
Personally this is what I do for both my personal systems and my servers 
at work - and that's pretty common, and since the latest stable kernel.org 
kernel tends to actually /be/ stable that approach has worked well for 
years.

Also not all vendors keep up with security fixes equally well, so it's a 
common (at least in my experience) attitude that if you want to keep 
up-to-date security wise you should just keep up with the kernel.org 
kernels and you are resonably safe.

Also, it is usually a pretty safe bet that if you need to use third party 
modules, you are very good off with a kernel.org kernel as that tends to 
be the reference kernel that stuff gets tested against (personal 
experience, I have nothing concrete to back that up with).

If the stable kernel.org kernel stops being stable and reliable a lot of 
users will be badly disappointed and will be forced to either stay with 
old insecure kernels or be forced to use vendor kernels with all the bloat 
that implies. That would be a sad state of afairs in my oppinion.

I guess the perfect situation would be if the kernel.org kernel would be 
stable enough and feature rich enough that the vendors didn't /need/ to 
supply anything else than the stock kernel from kernel.org - how to get to 
that point I don't know though.

just my 0.02euro


--
Jesper Juhl <juhl-lkml@dif.dk>

Re: New dev model (was [PATCH] delete devfs)

[Ben Hoskings]

On Fri, 23 Jul 2004 09:01, Andrew Morton wrote:
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.
>
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.

I'd like to throw my opinion into the discussion at this point too, for what 
it's worth.

I think the idea of forking off certain releases in the 2.6.x.0 form, to only 
recieve bugfixes and security updates, is a very good idea. A couple of 
points against it were raised above, but I think if it were approached the 
right way, they wouldn't be issues.

There wouldn't be a huge maintenance overhead, as

  -- The forks would only need to happen occasionally. When 2.6.y has advanced 
past 2.6.x (y > x) sufficiently (i.e. it has significant new functionality) 
and it has been released for sufficient time to iron out obvious bugs, then 
if it comes to be considered a particularly stable release, it would be a 
good candidate for freezing at 2.6.y.0. I would think this sort of thing 
would probably only need to happen once or maybe twice per every ten or so 
traditional releases.

  -- The only maintenance that would be needed on these frozen versions would 
be a backport of any critical bugfixes / security issues, when they occur.


The table on the front page at kernel.org could be augmented with an extra 
row, showing the most recent frozen release from the stable tree. Users who 
want a recent _vanilla_ kernel that is unchanging and hopfully highly stable, 
could choose it.

On Sat, 24 Jul 2004 06:57, Timothy Miller wrote:
> Does that mean that 2.6.21 and 2.6.20.1 are two separate forks of
> 2.6.20, one for development, and the other for stability?
>
> How is this fundamentally different from how it was done before with
> odd/even minor numbers?

IMO the process wouldn't mirror the old 2.x / 2.y model because it is much 
more fine-grained. With the old model, changes have to be backported to a 
kernel that is significantly older, and which potentially has seen 
fundamental changes in the releases between (i mean between 2.x -> 2.y). With 
the new model, a release 'freeze' could be made whenever deemed necessary, 
and since it will be a lot closer on the timeline to where the main 
development is happening, backporting the critical stuff should be a lot less 
of a headache.

The important part would be to not go overboard with release freezing, so 
there wouldn't be 10 frozen kernels to backport to. _That_ would be a 
headache.


There's my $0.02. :)

-- 
	Ben

Re: New dev model (was [PATCH] delete devfs)

[Bernd Eckenfels]

In article <200407261138.55020.ben@jeeves.gotdns.org> you wrote:
> I think the idea of forking off certain releases in the 2.6.x.0 form, to only 
> recieve bugfixes and security updates, is a very good idea.

Leave that to the vendors, they already do that.

Whats wrong with adding features which touch major parts of the code only to
2.7, and perhaps bacport them if they proof to be worth it?

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: New dev model (was [PATCH] delete devfs)

[Bill Davidsen]

Paul Jackson wrote:

> The direction presented to us now is having smaller, more continuous,
> steps in the head end, over having fewer larger, more disruptive steps. 
> Do we do all the incompatible changes in a big chunk, once every couple
> of years, or do we do them one a week, ongoing.

Do I read that correctly? You are suggesting doing big disruptive 
changes every week? I know what you mean, but this is just what many 
people don't want, being told that they have to give up cyrptoloop or 
devfs to get a better scheduler.
> 
> Now, I repeat, this is at the head end.  End users who want stability
> aren't feeding directly off kernel.org anyway.

Having been bitten by vendor kernels repeatedly, I would say that some 
are and some aren't. And people who want minor new features like a 
device driver or better scheduler don't want to rebuild a system from a 
base install just to get there. It's one thing to get all the new 
features of a 2.N to 2.{N+2} conversion, but it isn't worth a major 
reconfig to get there.
> 
> The affect downstream on real users is this.  If the head end operates
> in big chunky style, then as this big change flows downstream, it makes
> transitions for distros, service providers and middlemen more costly and
> difficult, creating expenses that must be passed on to the end user.

Do you suggest that many disruptive changes are less expensive than one 
every few years? There should be something between RHEL "stable for five 
years" and FC2 "run up2date on the hour" models. The stable series has 
been that in the past, and dropping any disruptive change into the 
stable series seems to belie the term stable.
> 
> Yes - damming up the flow of changes creates stability.  But if you're a
> middleman, you don't need Linus to choose where to build the dam, and
> when to open the flood gates.  It's more efficient for you to choose for
> yourself when to do that damming, based on your particular resources and
> customer needs, rather than have to deal with hundred year floods and
> draughts imposed on you by Zeus.

So everyman becomes his own vendor, if you want a minor feature you have 
to patch it into an old kernel which still works for you? This is a 
major change from the way stable vs. development has ever worked... It's 
not the pace of little things which troubles me, it's Reiser versions, 
and vanishing cryptoloop and devfs, and things like that which require 
major changes in a system.
> 
> The end user always gets their stability, if only because they won't
> upgrade a system that is "working".
> 
> And every change at the head end is disruptive for some poor slob.
> The only perfectly compatible change is no change at all.  We delude
> ourselves if we think we can separate the "safe" fixes and additions
> from the "unsafe" incompatible changes.  Better that we should expend
> some energy on smoothing out and minimizing the cost of change to those
> downstream from us.  This needs to be done the old-fashioned way, one
> change at a time.
> 
> The question is whether we impose, on all those downstream from us,
> occasional hundred year floods, or do we provide a steady stream, and
> let them build their own little beaver dams, as suits their various and
> diverse needs and business cycles.

No matter how you spin it, you are still talking disruptive change over 
and over vs. an occasional major rethink.
> 
> The great lesson of capitalism over communism is that a thousand free
> workers and investors, each optimizing their own little plot or
> portfolio, beats a single centrally imposed five year plan, even if the
> man pulling the levers is a genius such as Linus or Lenin (sorry, Linus,
> couldn't resist ...).
> 
Of course making the end users far more dependent on vendors didn't 
enter into this at all...

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: New dev model (was [PATCH] delete devfs)

[Bill Davidsen]

szonyi calin wrote:
> --- Geert Uytterhoeven <geert@linux-m68k.org> a écrit : > On
> Fri, 23 Jul 2004, [iso-8859-1] szonyi calin wrote:
> 
>>>And with new devepment model this expenses will be passed to
>>
>>the
>>
>>>end user when the kernel will not be stable enough and will
>>> crash. Do you you remember the 8k vs 4k stack problem for
>>>Nvidia binary kernel module ?
>>
>>You want a stable kernel, but you also want to rely on
>>binary-only kernel
>>modules?
>>
> 
> 
> No. I wasn't clear on that one. My example was wrong. AFAIK the
> 8k/4k stack kernel problem were causing problems for other 
> people too.
> 
> 
>>The Linux kernel people cannot guarantee stability with
>>binary-only kernel
>>modules. And the Linux kernel people cannot solve that
>>problem...
>>
> 
> 
> I underestand that. 
> However hpa told me that the stability of the 2.6 kernel will 
> not suffer.

And akpm posted that he intended to remove cryptoloop, while others are 
calling for the end to devfs. Not having features disappear is part of 
stable, I would think, not just "not oops more often."

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: New dev model (was [PATCH] delete devfs)

[Ben Hoskings]

On Monday 26 July 2004 12:12, Bernd Eckenfels wrote:
> In article <200407261138.55020.ben@jeeves.gotdns.org> you wrote:
> > I think the idea of forking off certain releases in the 2.6.x.0 form, to
> > only recieve bugfixes and security updates, is a very good idea.
>
> Leave that to the vendors, they already do that.
>
> Whats wrong with adding features which touch major parts of the code only
> to 2.7, and perhaps bacport them if they proof to be worth it?

I guess it's pretty similar in practice. I brought it up because the idea of 
freezing releases at 2.6.x.0 is more fine-grained, and as such it seemed to 
me that it would be less of a maintenance overhead.

Although labels aside, I suppose the two systems are acheiving the same thing 
in the end.

>
> Greetings
> Bernd

--
	Ben

Re: New dev model (was [PATCH] delete devfs)

[Paul Jackson]

Bill wrote:
> No matter how you spin it, you are still talking disruptive change over 
> and over vs. an occasional major rethink.

I will have to bow out of trying to further justify what was decided at
the Summitt with my marginalia.  My explanatory gloss are not sufficient
to persuade some dissenters ... so be it.

My gut is that this is a good direction.  I trust others can speak to
it with more authority.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: New dev model (was [PATCH] delete devfs)

[Krzysztof Halasa]

Ben Hoskings <ben@jeeves.gotdns.org> writes:

> I think the idea of forking off certain releases in the 2.6.x.0 form, to only 
> recieve bugfixes and security updates, is a very good idea. A couple of 
> points against it were raised above, but I think if it were approached the 
> right way, they wouldn't be issues.

I think so.

I assume the numbering will stay the same, i.e. 
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 8
EXTRAVERSION =-rc2

will eventually become
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 8
EXTRAVERSION =

and then possibly

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 8
EXTRAVERSION =.1 (or -pl1 etc.)

so it won't require changing scripts.

> IMO the process wouldn't mirror the old 2.x / 2.y model because it is much 
> more fine-grained. With the old model, changes have to be backported to a 
> kernel that is significantly older, and which potentially has seen 
> fundamental changes in the releases between (i mean between 2.x -> 2.y).

I think so. The scheme is somehow similar to -AC (Alan Cox') tree -
and we all know that it (the process etc) was working very well.
-- 
Krzysztof Halasa

Re: New dev model (was [PATCH] delete devfs)

[Krzysztof Halasa]

Bernd Eckenfels <ecki-news2004-05@lina.inka.de> writes:

> Whats wrong with adding features which touch major parts of the code only to
> 2.7, and perhaps bacport them if they proof to be worth it?

Someone has to do the actual backporting.
-- 
Krzysztof Halasa

Re: New dev model (was [PATCH] delete devfs)

[Krzysztof Halasa]

Bill Davidsen <davidsen@tmr.com> writes:

> And akpm posted that he intended to remove cryptoloop, while others
> are calling for the end to devfs. Not having features disappear is
> part of stable, I would think, not just "not oops more often."

OTOH removing things declared "obsolete" for a long time doesn't make
it unstable - does it?
-- 
Krzysztof Halasa

Re: New dev model (was [PATCH] delete devfs)

[Adrian Bunk]

On Thu, Jul 22, 2004 at 02:55:39AM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> wrote:
> >
> > Changes that remove functionally like Greg's patch are hopefully 
> > still 2.7 stuff - 2.6 is a stable kernel series and smooth upgrades 
> > inside a stable kernel series are a must for many users.
> 
> I don't necessarily agree that such changes in the userspace interface
> should be tied to the kernel version number, really.  That's a three or
> four year warning period, which is unreasonably long.  Six to twelve months
> should be long enough for udev-based replacements to stabilise and
> propagate out into distributions.
> 
> That being said, mid-2005 would be an appropriate time to remove devfs.  If
> that schedule pushes things along faster than they would otherwise have
> progressed, well, good.
>...

I'm currently wondering whether part of our discussion might be about a 
non-issue:

It's true that there's not a pressing need for opening 2.7 today.

But do you assume that this will still be true one year from now?

If 2.7 will open during the next 12 months, "mid-2005" would still be 
after 2.7 opened, and such non-urgent cleanups could then go into 2.7 .

cu
Adrian

-- 

       "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 Seed

Re: New dev model (was [PATCH] delete devfs)

[Bill Davidsen]

On Wed, 28 Jul 2004, Krzysztof Halasa wrote:

> Bill Davidsen <davidsen@tmr.com> writes:
> 
> > And akpm posted that he intended to remove cryptoloop, while others
> > are calling for the end to devfs. Not having features disappear is
> > part of stable, I would think, not just "not oops more often."
> 
> OTOH removing things declared "obsolete" for a long time doesn't make
> it unstable - does it?

Obsolete for a long time? This is a new feature in 2.6! It was just added
and was the hook that got some people to go to 2.6 in some cases, to have
some useful security in laptops. To remove it would effectively block
following newer kernels when security holes are found, since dm-crypt
would mean installing new software, training the support group,
reformatting the disk to generate a partition to use, etc.

When major new features just added to a stable series vanish after they
are adopted I most definitely do call that unstable.

And dm-crypt is vulnerable to the same types of attacks, it's just harder
to use.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: New dev model (was [PATCH] delete devfs)

[Krzysztof Halasa]

Bill Davidsen <davidsen@tmr.com> writes:

>> > And akpm posted that he intended to remove cryptoloop, while others
>> > are calling for the end to devfs. Not having features disappear is
>> > part of stable, I would think, not just "not oops more often."
>> 
>> OTOH removing things declared "obsolete" for a long time doesn't make
>> it unstable - does it?
>
> Obsolete for a long time? This is a new feature in 2.6!

Well, actually I was thinking about removing devfs in 2005.
-- 
Krzysztof Halasa

Re: New dev model (was [PATCH] delete devfs)

[Bernd Eckenfels]

In article <m3d62fj06x.fsf@defiant.pm.waw.pl> you wrote:
> Someone has to do the actual backporting.

Well, thats not a  problem, since if a feature is not backported nobody is
interested and it wont affect the stable stability.

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: [Kernel] Re: New dev model

[Thierry Vignaud]

"Svetoslav Slavtchev" <svetljo@gmx.de> writes:

> once again, sorry for this way of replying,
> could you keep me CC'd as i'm not subscribed to lkml

(...)

> That could be done by sending in smaller patches that remove devfs
> calls from drivers.  If nothing in the kernel is using devfs, then
> there is no reason to keep it around anymore...

well actually removing such bits from dac960.c and cciss.c would
restore devfs support for them :-(

> please don't do it /*at least not in the following two months :-)*/
> 
> what does this buy us ?
> 
> once again about the upcoming Mandrake 10.1, we already have readded
> devfs support to isdn, should we start tracking bk-head for such
> patches that remove devfs support from drivers and revert them ?
> should we stay with 2.6.7 (or eventually 2.6.8)?  there is really no
> time to integarate/test udev as replacement of devfs for the next
> release.

the odds're high we'll go out with udev by default.
it works smoothly for most devices (dvb and a few others seems missing
but patches are pending).

drakx installer is know fully aware of it (as of today's cvs)