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: http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/udev-026-4.src.rpm 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...) Thanks, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part
