udev in initrd

[Owen Taylor]

On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> On Mon, 2004-07-05 at 11:44 +0200, Owen Taylor wrote:
> > (*) I know some people (yes, you, Jeremy) have serious reservations
> >     about the details of how udev is implemented. And I really
> >     just mean "dynamic creation of device nodes on a ram filesystem".
> >     But I don't think the fact that udev is too 
> >     bloated/complex/policyless/whatever to run in Anaconda should keep
> >     us from trying to start fixing these problems for installed
> >     systems.
> 
> It's not anaconda that worries me the most.  If we're not doing any sort
> of different device naming, then with my anaconda hat on, I'll just
> stick my fingers in my ears and pretend it doesn't exist.  "Dynamic
> creation of device nodes on a ram filesystem" actually already happens
> in anaconda, so it's not like it's a foreign concept or something that
> I'm completely against.  I have my doubts as to the value of it on a
> general purpose system, but in your weird diskless case, sure, it makes
> sense.  Granted, I can implement it as something far simpler than udev.

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.

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

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.

> 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?

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.

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

Regards,
		    			    Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040706/5e7b1a17/attachment-0002.bin