[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: udev in initrd

On Thu, 2004-07-08 at 04:11, Greg KH wrote:
> 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.

For some reason the udev package we have in rawhide now:

Seems to fall into the category of "complex rule set full of shell
scripts" ... in some testing I was doing a while ago, an initial
run of udev to populate /dev was executing ~3000 processes.

If you have time to take a look at that configuration of udev, I'd be
interested to know whether you think it's:

 - Just poor configuration of udev to achieve something that could
   be done much more simply and efficiently.

 - A policy that "pretty much requires" shell scripts. (Not that I can
   imagine what fixed policy is easier to implement as a rats nest
   of shell scripts...)


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]