how to check if hal is ready

Artem Kachitchkine Artem.Kachitchkin at Sun.COM
Fri Mar 3 17:16:47 PST 2006

>> like "info.scan_state" property, with values 'in_progress' and 'done'.
> If so, it would be also possible to have a callback, like
> libhal_rescan_complete(). The ideal solution would be something
> like libhal_device_scan_complete(), but ...

You're thinking in terms of libhal again... Libhal is just a wrapper. If 
there is such a property, you simply subscribe to "PropertyModified" 
signal, whatever D-BUS binding or wrapper library you're using.

>> free to scan or not scan for volumes whenever it feels like, or 
>> depending on runtime conditions known only to HAL.
> Can you explain to me the last two lines? I mean, why would it be a
> problem to eg invoke a signal to a user (ie through LibHal) after the
> probing/searching for volumes has finished?

We could add a signal for that, but we could instead add a property and 
use the existing "PropertyModified" signal. Less code change that way.

> I noticed that in hald/blockdev.c

hald/linux2/blockdev.c, actually., which is critical: I'm not talking 
about Linux-specific implementation, I'm talking about HAL in general.

> I guess this is what you mean. After that, blockdev_callouts_add_done()
> is called and the device is removed from the TDL and added to the GDL.

That's what happens in the Linux backend. In general, device is added to 
GDL after all pre-probe (info.callouts.preprobe), probe and add 
(info.callouts.add) callouts are finished.

> So when a volume is added, that's a separate hotplug event?

Depends on HAL implementation, but it doesn't matter ("hotplug events" 
in the Linux backend are not really what they sound like). What matters 
is that when a volume is added, that's a separate HAL device object and 
a separate "DeviceAdded" signal.


More information about the hal mailing list