HAL deprecation

[Adam Williamson]

This just occurred to me...

HAL is going to be deprecated in future. Fedora is trying to get rid of
it for Fedora 13. Other distros will wind up following somewhere a bit
further down the road.

So, what to do with synce-hal? I think most things are migrating to use
udev instead. Does udev currently provided everything needed for what
synce-hal is doing?

[Mark Ellis]

Post by Adam Williamson
This just occurred to me...
HAL is going to be deprecated in future. Fedora is trying to get rid of
it for Fedora 13. Other distros will wind up following somewhere a bit
further down the road.

Trust Fedora to rush it.

Post by Adam Williamson
So, what to do with synce-hal? I think most things are migrating to use
udev instead. Does udev currently provided everything needed for what
synce-hal is doing?

You are indeed correct, hal is going to be deprecated. As with all
things in life, it's not as simple as I'd hoped ...

Effectively, udev replaces hal. Of course, udev is a linuxism, and no
one seems to have put much thought into what happens on *BSD etc. So,
I've started a new package called synce-connector, connector in svn
trunk, based on synce-hal, to build as a hal addon or run from a udev
event. It won't do much yet, but it's coming along.

The other problem is that udev doesn't allow for setting arbitrary
attributes on the device like hal does, so the udev version needs it's
own dbus interface like odccm does. For various reasons, this requires
some code reworking to have the interface as soon as possible. On the
plus side, this fits in nicely with something myself and Guido have
discussed recently about flagging up connection problems. Guido, I'm
trying to move all the connection stuff in to the device object so the
hal / dbus interface id there from the start, which should make the
firewall thing easier, so hold for a bit on that patch.

Mark

[Ilya Bakulin]

On Sat, 6 Mar 2010 09:26:27 +0000

Post by Mark Ellis
Effectively, udev replaces hal. Of course, udev is a linuxism, and no
one seems to have put much thought into what happens on *BSD etc.

Indeed. BSDs (at least FreeBSD) have devd daemon, it's able to trigger some events when devices are connected/disconected. But it's unable to assign any properties to them. It is designed in the UNIX way -- a tool like devd should notify the world about an event, but it shouldn't know what should be done when this event happens :-)

As I know, hal is going to be replaced by "DeviceKit". Am I right that it's something tightly coupled with udev?

[Mark Ellis]

Post by Ilya Bakulin
On Sat, 6 Mar 2010 09:26:27 +0000

Post by Mark Ellis
Effectively, udev replaces hal. Of course, udev is a linuxism, and no
one seems to have put much thought into what happens on *BSD etc.

Indeed. BSDs (at least FreeBSD) have devd daemon, it's able to trigger some events when devices are connected/disconected. But it's unable to assign any properties to them. It is designed in the UNIX way -- a tool like devd should notify the world about an event, but it shouldn't know what should be done when this event happens :-)

Ok, that sounds like udev, so that's good. Any idea how to hook
something into devd ?

Post by Ilya Bakulin
As I know, hal is going to be replaced by "DeviceKit". Am I right that it's something tightly coupled with udev?

For our purposes, DeviceKit is udev.

Mark