udev in initrd

[Owen Taylor]

On Wed, 2004-07-07 at 00:38, Jeremy Katz wrote:
> 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. 

How much of an optimization though? Creating several hundred device
nodes on a ram filesystem is going to take a tiny fraction of a
second. I admit the 18,000 files don't matter much either (unless
you are continually installing in which case it's 20 seconds an
install...)

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

If that's to have a single configuration file used both by MAKEDEV and
udev; sure that's another workable solution. But are we doing anything
to get there?

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

I'm not talking about how many things have to be changed in the
system image, I'm talking about how many possibilities there are for
bugs to be present in one setup and not in the other. 

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

On the philosophical questions, sure we can agree to disagree. But
I'm really concerned that there has been an "agreement to disagree"
on a technical level. Parts of the system are beginning to require
at least a partially dynamic /dev, and the maintainers of those areas
are assuming udev. But in other areas, we seem to be dragging our feet
and saying that doesn't work.

The reason I'm pushing for going to a fully dynamic /dev always is
that forces the issue. Dynamic /dev is forced to really work, not
just be some checklist item which works in a few test configurations.

It also (in my opinion) simplifies the system. Getting hardware to 
"just work" seems hard enough to do with one configuration path that I
can't really see why people want to have *two* configurations.

But, yes, there other ways that would work. But if we are going to
do it some other way, where's the roadmap for that? Where's the
explanation of how we *are* going to do it? 

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

As Alan said, it's an implementation issue. What we need to implement
is a device naming policy, and a mechanism for implementing that
policy at package-build-time/boot-time/hotplug-time/whatever.

If that mechanism involves udev and a bunch of shell scripts, that
may be a very inefficient way of implementing the policy, but, it's
not introducing over-configurability into the system. What's 
configurability for the udev maintainers is not configurability for
our end users.

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

Any finite set of device naming schemes can be implemented in a 
C program. And even something quite complex like naming by path
to the device isn't going to be a lot of code. 

But really, I'm not sure I follow your train of logic. The fact that
udev allows implementing arbitrary crack-rock device naming schemes
doesn't imply to me that if we go with a solution based on udev
now we'd then have to allow implementing arbitrary crack-rock
device naming schemes forever after.

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

Where's the equivalent to:

 http://people.redhat.com/otaylor/fosdem2003/file-selector.html

Then?
 
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040707/a4068bed/attachment-0002.bin