[rfc] Activating Common Services

Richard Hughes hughsient at gmail.com
Tue Jun 19 05:14:14 PDT 2007


Guys,

I've build rpm's of my latest patch, and all appears to be working well
on my F7 system. I'll get on and write the unit tests, but I wanted to
spend a moment discussing actually _activating_ services like HAL and
NetworkManager.

Naively, I called:

sudo killall hald
dbus-send --system \
	--print-reply \
	--dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer_backlight_1 \
	org.freedesktop.Hal.Device.LaptopPanel.SetBrightness int32:1

Which failed with:

Error org.freedesktop.DBus.Error.UnknownMethod: Method "SetBrightness"
with signature "i" on interface "org.freedesktop.Hal.Device.LaptopPanel"
doesn't exist

Even tho the hald process is successfully started.
Subsequent dbus methods on LaptopPanel work as expected.

I think the problem is that HAL only adds the devices after it registers
itself on the bus, so:

sudo killall hald
dbus-send --system \
	--print-reply \
	--dest=org.freedesktop.Hal /org/freedesktop/Hal/Manager \
	org.freedesktop.Hal.Manager.DeviceExists string:moo

works as expected, and activates the system service.

So, is HAL wrong to register itself on the bus before adding all the
coldplug devices (other services like NM do similar things to this too),
or should we have some sort of "activation" interface that is always
present as soon as the service appears on the bus and also lets us shut
a service down:

org.freedesktop.Hal.Activation.Start
org.freedesktop.Hal.Activation.Stop

This would be called by the first session application that wants to
cause the service to be activated, and also let the service know when
it's finished. For instance bluetooth transfer software for GNOME could
ask the bluetooth service to start, raising the refcount by one. When
files are finished copying, the Stop method can be called, and if the
refcount is zero then the system service can unload itself (also
disconnecting from the hardware in the process).

(ignoring the fact we have stale refcounts if the bluetooth file
transfer program crashes...)

This would also let daemons that have to sync or write files to disk
know that these need to be shut down.

So, comments?

Richard.




More information about the dbus mailing list