Fedora Core 3

[Kay Sievers]

On Thu, 2004-07-08 at 14:21 -0400, Jeremy Katz wrote:
> On Thu, 2004-07-08 at 01:18 -0700, Greg KH wrote:
> > On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote:
> > > On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote:
> > > > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
> > > > > I'm not averse to using it, but if you're not changing the device
> > > > > names, most of the useful functionality could be done just by
> > > > > using the dev.d callouts without actually having udev manage
> > > > > /dev.
> > > > 
> > > > That's a good point, and should be worthy of allowing udev to be
> > > > installed by default.  That way things like HAL and gnome-vfs can still
> > > > work properly, as they chain off of those callouts.
> > > 
> > > Basically, yes... and that then makes for a much smaller and simpler
> > > udev.  nanodev :)  Basically, just the callouts so that HAL can be made
> > > happy and you have a nice static /dev.  
> > > 
> > > None of the complicated "which ruleset and set of shell scripts do I
> > > need to run", etc.  Makes things far more predictable, lower impact and
> > > actually gives the real benefit that people are wanting to take
> > > advantage of without the more controversial bits.
> > 
> > Wow, 58kb is too big for you?  :)
> 
> Binary size does not alone dictate complexity.  And that's with a
> completely separate libc from everything else in the world which then
> also includes kernel headers for building?  This does not count as small
> and simple in my world.  
> 
> > Sure, I could strip udev down to something even smaller like what you
> > mentioned, but I don't think it will be worth it to anyone, as you can
> > operate udev in that same mode today with no changes needed to it.
> 
> Except that with the _ability_ to do so, people think that's how they
> should be doing it and then you end up needing to be able to pull
> anything into an early boot environment.  This is especially the case
> since all of these little utilities are part of udev.
> 
> Why not have udev just be the bit for the callouts and then both HAL and
> some dynamic-deviced hook into it?  (And then static dev is still a
> perfectly reasonable alternative instead of having udev dictate a policy
> of dynamic /dev ;)

Oh, please don't mix the 'low-level' udev with the recent desktop stuff.
I personally would draw a strong line between both environments. We need
to care about both. Isn't it more you, that wants to 'dictate', than the
ability to put rules in udev? :)

The creation of udev was mainly motivated as a replacement for devfs and
works pretty well as that. I spent many night to get all the stuff
working with klibc and the ability to run CALLOUTS even without _any_
shell present on the system. :)
The convincing point and the main goal of udev was and is to abstract
the kernel device enumeration from the users view of the devices. During
the creation of udev, we had contact to the guys at OSDL who are
managing boxes with several hundreds of hard disks. They seemed pretty
happy with the architecture and the scsi_id callout. You will never be
able to do something similar, without it.

Ok, I only have 3 boxes with just one disk each, but I'm really happy,
that I can connect a USB-storage device to my server for backup and it's
everytime the same dev-node, which is in hard coded in fstab. It works
pretty well and is far from 'bloat'.

The HAL and desktop stuff is a complete different area. In the near
future, no average desktop user will need to know anything about device
nodes. HAL will handle this for you.

We still have, and probably will have these two worlds forever. I'm
happy with the picture, HAL draws for the desktop, but I still use
shell-script to do my backups, even for my notebook and it's pretty nice
to have a reliable way to match my devices and create the corresponding
node with a stable name, so the scripts can just catch it.

udev is the 'bridge' between these two worlds, we intentionally removed
the dbus stuff from udev, for this reason. Any higher level application
should use the information available from HAL, but things like bus-
devices connected to a headless box, are clearly the field for udev and
it's nice not to rely on several daemons to do a simple task like this.

What exactly is the problem, you are talking about? Please come back to
a sane discussion. I don't have any feeling about the use of udev in
initrd, but I'm happy to do any needed changes to udev, if it has more
substance than 'strip it down'. 

Thanks,
Kay