udev in initrd

Greg KH greg at kroah.com
Thu Jul 8 08:11:33 UTC 2004


On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote:
> > "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.

Um, udev is a "simple C program that reads a policy description file and
names devices".  It doesn't execute any shell scripts, unless you want
it too (like the current package in the Debian tree, what horrors...)

Compiled against klibc, udev ends up at 58Kb, static.  That's only 4
times bigger than /bin/true (which is dynamically linked against glibc
too...)  /bin/cp is bigger than that (again, dynamically linked...)

Look at the default udev rules that it ships with.  No shell scripts.
No complex rules.  And that gives you the sane device naming policy that
Red Hat uses today.

Yes, you can use udev to call fancy shell scripts if you want to (to
emulate the devfs naming rules, you pretty much have to), but that's
what makes udev powerful, and an answer to pretty much all users.
There's no reason Red Hat has to ship udev using a complex rule set full
of shell scripts.

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

Yes, and as it seems to fit your description, that's an even bigger
advantage :)

thanks,

greg k-h





More information about the devel mailing list