udev in initrd

[Florian La Roche]

> 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.

I think we will have to provide more flexibility here. I personally
also like to populate /dev at install time and then don't worry about
scanning devices on each boot and I personally still don't use devices
I attach at runtime to my systems. I think I would also disable udev
on startup for my machines the same way I disable kudzu now and some
other scripts on bootup I don't need.

I still think this is useful to other people. udev has been tested against
pam, selinux and provides this greater flexibility. The comments here have
been right. E.g. there is no reason the list of devices within the
udev database should not be synchronized against our static makedev package
and many other changes probably also make sense.
In my opinion this means further integration of udev is needed, not keeping
it away. Incrementally adding to udev is way better than trying to come
up with a new way to solve the same things.

> > 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. 

And I think people are right if they want to have machines running without
udev, but also see that for other setups it will be needed.
I'd argue that way more testing is needed until we know for sure that
a tmpfs on bootup is working fine, but I don't see a reason to stop further
development in that direction and thus further integration of udev.

> Yes, but does that mean that we should add more overly configurable bits
> when something far simpler would suffice?

Couldn't you add to udev to make it simpler again?

> 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.

It's gonna be needed in the future. (Blinking, colored, flashing devices
and my daughter will love them... ;-)

> 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 :-)

You have valid points. udev is still under more active development and
I hope some of the concerns are picked up and resolved in newer releases.
gtk is also not dying due to revamped additions of a file chooser, even
if many apps might suffer from the first version of it or have written
their own implementation of it.

greetings,

Florian La Roche