Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Rob Landley]

On Saturday 03 December 2005 18:20, Greg KH wrote:
> On Sat, Dec 03, 2005 at 11:50:20PM +0100, Matthias Andree wrote:
> > 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.
>
> > 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:
...
> > 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
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/