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