some changes for (slightly) faster boot

[Bill Nottingham]

David Zeuthen (david at fubar.dk) said: 
> Which is planned to be added upstream in hal - in a nutshell, what is
> needed for auto configuration of hardware is some mechanism to store 
> configuration data about physical and logical devices in a persistent 
> manner [1] accessible through a unified interface [2]. Once you have
> that, it's not really hard to replace existing or write new policy
> agents.

A good chunk of this is per-system, not per device. The main
purpose of most of the aliases these days is to enforce some sort
of reasonable ordering, which is needed in lieu of persistent device
naming [1].

Realistically, all the aliases written by kudzu these days are for is:
a) enforcing ordering among scsi devices
b) enforcing ordering among sound devices
c) allowing network devices to be brought up if the driver isn't already
   loaded (which usually means it's been manually removed)
d) parport_serial (its own weirdness)
e) allowing video devices to be loaded on demand

c) and e) could conceivably go away right now.

If you're looking per-device, you can add this sort of ordering/indexing
there, but I'm not sure that's the most efficent.

> > Of course, foisting complication on userspace from the kernel seems
> > to be the way to go these days, judging by udev. :)
> > 
> 
> Heh, actually one thing I like about udev is the fact that it made
> a lot of *existing* bugs and hacks like inserting "sleep 2" visible.
> Oh wait, Greg KH already explained this here
> 
>  http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html
> 
> and in surrounding messages :-)

Oh my goodness.

OK, first. 'sleep 2'? Part of the udev stack still is userspace busy
waiting on the kernel. It's not making the hack more visible, it's
just moving it somewhere else.

That's the majority of what udev does... it just merely moves
all the races and oddness to userspace. It's a case of the kernel saying
'here, I don't want to deal with these problems, I'm going to
break your access model based on the deficiences of some buses, have
fun reorienting to fix it.'

And then leaves userspace to clean up the mess.

For example, because of the wonders of udev:
  
- Take the example of a sound card. You want to restore the volume
  on startup.
  
  Under previous configurations, you needed to know the name of the
  command to restore sound. You then added it to modules.conf.
  
  Under udev you need to create a dev.d script to run, which means:
  
  - your script needs to know the sysfs layout of the device,
    which of course never changes (to avoid running extraneously)
  - because you never get a 'this driver is done creating devices'
    signal, you need to either
    a) sleep a random amount of time
    b) run the restore command multiple times

  Repeat this scenario for other devices.
  How is this progress?

- Say an app wants to use some sort of random device, not
  really tied to a piece of hardware.

  Under previous configurations, they opened the device, and
  either got ENODEV, or continued successfully. [2]

  Under udev, either:
  
  a) it works. This means that the driver has been loaded
     and udev has already run, hopefully. This means that some
     other process:
     
     - has loaded all the device modules. Ergo, every user
       has floppy, loop, nvram, etc loaded in nonswappable
       kernel memory.
     - has made random device nodes for them and trusted
       that kmod works. So, what exactly was the point of a dynamic
       /dev then?

  b) it fails with -ENOENT
      Hopefully, that means there's no device. But if
      someone decided to remove a module like nvram earlier...?
      Then the *app* needs to know what driver to load, and
      create its own dev.d script to notify itself that the
      device is ready.

I'm sure there can be more examples.

It's true that there are many classes of devices that require
an asynchronous framework to work correctly. I'm not convinced
that adding the same handicaps to all the device types, Harrison
Bergeron-style, is a well thought out design. It's akin to
making apps that use dlopen() or apps that link library dependencies
parse text files for every link libraries because some platforms' linkers
are deficient.

Bill

[1] Yes, I've seen the examples in udev or the stuff proposed by
    OSDL. Next joke.
[2] Yeah, I know the device name can change with udev. Doesn't 
    solve this aspect without patching your apps either.....