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
