probing

[Artem Kachitchkine]

Some device properties are cheap for HAL to get, say from sysfs or 
procfs. Most of them come from kernel infrastructure and/or drivers. 
They might have been collected at driver initialization and such, but 
are cached in RAM in one way or another.

Others are more expensive to get, requiring to open a device, issue 
reads or ioctls, because they are not cached, either because they are 
volatile or for other reasons. It can be quite resource intensive 
process, using CPU time, DMA and kernel memory, causing disk activity, 
etc. Expensive properties are acquired by probing helpers.

HAL uses a pretty aggressive caching strategy. For instance, when system 
is booting, HAL would probe *everything* it can probe. Doesn't help boot 
time.

The problem can be partially addressed if the OS can run HAL in parallel 
with other startup services and console login prompt does not depend on 
HAL to finish initialization. That's OS specific: I know it is possible 
in Solaris using SMF [1], I'm curious how things are looking in Linux 
these days.

Another way to decrease probe time is parallelize probing: parent node 
can probe all its children in parallel, e.g. volumes on a disk. Probe 
time will not reduce much on a typical laptop or desktop, but can be 
significant on large machines.

Another idea might be worth playing with, is some sort of on-demand 
probing mechanism. E.g. looking up an expensive property could trigger 
probing. Kinda like paging in. So for instance, an webcam application 
can quickly get a list of available webcams (because device category is 
a cheap property); but when a user selects one from the list and the app 
  looks up properties for this particular UDI, only then we probe and 
get complete device information.

Just throwing it out there,
-Artem.

[1] http://www.opensolaris.org/os/community/smf/