udev in initrd

[Jeremy Katz]

On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote:
> On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> The value of it on the case of the writable root filesystem is that
> you only have one path for how the system works, not two. Changes
> to device naming only have to be put into one place. Eventually we
> can simple drop the dev package and it's 18,000 files.

But exactly what does the 18k files cost it?  Similarly, we could drop
ldconfig runs in %post and just have all of the symlinks created on each
boot, but that doesn't strike me as a good idea either.  It's a useful
optimization to have them laid down by the install because then you
never have to create new device nodes.  Which can be a lot of device
nodes per device.  Changes to device naming is simple -- just make what
gets used for the creation the same as what gets used in the dev
package's spec file.  Nice and simple to do with current infrastructure.

> The less we have to modify the root file-system in our normal
> configuration, the less "weird" the diskless case is.

One tweak in /etc/sysconfig/foo doesn't seem overkill -- it could even
be something that's used for more than one thing (as I'm fairly certain
there will have to be other things that happen slightly different in the
diskless case)

> Plus we can't get away from the fact that /dev really is a dynamic
> system. Even if we ignore hotplug, we are modifying the permissions
> on it for the console user stuff. As such writing these changes to
> disk across reboots is wrong.

I disagree.  We'll just agree to disagree here. 

> > My bigger concern is that udev has _zero_ policy.  It basically is a
> > "well, we want to let people do what they want" system.  Which is no
> > better than doing nothing at all.  And then, when you try to put it into
> > initrds, you have to allow the full range of shell utilities which is
> > just absurdity.  If we're willing to say "this is our policy, if you
> > change it, you get to make changes to other things too so that they keep
> > working", that's fine and then udev could be almost reasonable (although
> > I still think it's overkill)
> 
> There's a lot of other components of our system which are absurdly
> over-configurable in ways that would badly break the system - the
> X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> over-configurability into a working system one of the main 
> OS-assembly tasks?

Yes, but does that mean that we should add more overly configurable bits
when something far simpler would suffice?

> Clearly there has to be a policy about how devices are named; it's
> just one of the things that has to be there for a stable usable
> system. Having a simple C program that can read a policy 
> description file and name devices would certainly be vastly more
> efficient way of doing things than all the shell scripts that 
> udev runs.

Except that with what udev currently allows, you can't do so with one C
program...  because everyone wants a different way to do it.

> But udev exists now, and that's a big advantage for it.

Existence doesn't necessarily make something the best solution to a
problem.  In cases with significant architectural impact on the system,
it's far better to take a little bit longer and get a better technical
solution than to throw in something just because it's there.  I'll just
point to the file choose in gtk as an example here :-)

Jeremy