probing

[Danny Kukawka]

On Friday 13 January 2006 23:19, Artem Kachitchkine wrote:
[...]
> 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. 

We handle this with parallel boot/start services and start e.g. on SUSE hald 
as early as possible.

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

We (SUSE) plan currently some test with Itanium and S390 and some hundreds of 
devices to find out where the bottle necks are in HAL under Linux are. If we 
know more we could speak about optimize the speed. 

IMO we could maybe also change some probing prozesses to addons or callouts 
which started and add keys parallel after anouncing/adding the device. Under 
linux one could be probe-smbios but I don't think that this reduce the 
startup of hald significant.

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

Not sure if this is such a good idea, because you would have this information 
all the time available without any delay or waiting (e.g. probing some serial 
devices or e.g. scanner can need very long time). In the most cases IMO you 
would ask hal and get directly a answer or you listen on dbus/hal to be 
informed if a special device/property is added/changed. 

Cheers,

Danny