Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

[Greg KH <greg@kroah.com>]

On Mon, May 04, 2009 at 08:55:34PM +0200, Michael Riepe wrote:
> 
> 
> Kay Sievers wrote:
> > On Mon, May 4, 2009 at 19:54, Michael Riepe
> > <michael.riepe@googlemail.com> wrote:
> > 
> >>>The problem is not the missing events, they could be pretty easily
> >>>recovered from sysfs with just another special hack to run at bootup -
> >>>it's the time it takes to bring up the engine to bootstrap /dev, to
> >>>allow us to start any other process which looks for devices. Today,
> >>>udev mounts /dev as a tmpfs, and at that point it is obviously empty,
> >>>and needs to be filled, and nothing else can reliably run at that
> >>>time.
> >>
> >>And what about mounting /dev from an already populated image? Or, even
> >>faster, using the /dev directory of the root fs? That way, the device
> >>nodes would be present as soon as / is mounted, without any additional
> >>overhead, except the very first time the system boots (in case you
> >>choose not to populate /dev with a default set of device nodes in advance).
> > 
> > 
> > Dynamic device numbers! A static /dev does not work at all for many
> > subsystems, not to mention the risk you take by talking to the wrong
> > device pointed to, by your incorrect static device nodes. It's not an
> > option at all today, and it will get much worse in the future.
> 
> Maybe it's just me, but my devices end up being numbered the same after
> every reboot. Unless I add or remove devices to/from the system, of course.

It's just you :)

I have machines here that enumerate their USB devices on every other
boot in different ways.

I have one fun laptop here that enumerates the PCI bus in different ways
depending on how it feels at the moment.

Nothing about either of these busses is deterministic, nor will it be
changing to be that way in the future.

> Unfortunately, that doesn't mean that it will always stay that way.

Exactly, it will not.

thanks,

greg k-h