Fedora Core 3

[Jeremy Katz]

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

Jeremy