Porting HAL to FreeBSD

David Zeuthen david at fubar.dk
Sat Jun 19 08:46:55 PDT 2004


On Fri, 2004-06-18 at 15:26 -0400, Joe Marcus Clarke wrote: 
> Given the recent discussions on including Utopia in GNOME 2.8, I thought
> it prudent to take a look at what would be involved to get HAL working
> on FreeBSD.

That's great, I really appreciate that you are looking at this.

>   The Linux 2.6 extensions to HAL rely heavily on sysfs. 
> Would it be possible to port HAL to FreeBSD without requiring sysfs? 
> That is, does HAL itself require sysfs, or is just the Linux 2.6
> implementation of HAL that uses it? 

The source for the daemon is basically structured like this

hald                  - OS-independent code, HalDevice, DBUS interfaces
hald/linux/           - Linux 2.6 stuff
hald/linux/libsysfs   - Local copy of libsysfs

OS specific implementations basically entail implementing the functions
specified in hald/osspec.h:

void osspec_init (DBusConnection * dbus_connection);
void osspec_probe ();
DBusHandlerResult osspec_filter_function (DBusConnection * connection,
                                           DBusMessage * message,
                                           void *user_data);

so, on osspec_probe you'd build the device tree. On Linux we handle
device hotplug by sending DBUS messages to the HAL daemon; these we
intercept in osspec_filter_function(), any D-BUS method call not handled
by the HAL daemon itself get transferred to that function.

There is still some non-Linux specific code in hald/linux that should be
moved to hald/common at some point.

>  If an application supports HAL,
> does it assume sysfs exists or libsysfs is present?

Applications simply use the D-BUS API, for instance from Python the D-
BUS bindings allows very easy usage such as 

    bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
    hal_service = bus.get_service('org.freedesktop.Hal')
    hal_manager = self.hal_service.get_object(
                            "/org/freedesktop/Hal/Manager",
                            "org.freedesktop.Hal.Manager")
    devices = hal_manager.GetAllDevices()

or C applications can use libhal for convenience. libhal should be as
portable as DBUS is, which when DBUS is at 1.0 should be any UNIX-like
system. The OS specific parts are to be in hald/<osname>.

So you probably want to start with just creating a dummy device, much
like the FakeRoot device Joe Shaw added some time back by this

    fakeroot = hal_device_new ();
    hal_device_property_set_string (fakeroot, "info.bus", "unknown");
    hal_device_property_set_string (fakeroot,
                                    "linux.sysfs_path_device",
                                    "(none)");
    hal_device_property_set_string (fakeroot, "info.product",
                                    "City of Lost Devices");
    /*hal_device_property_set_bool (fakeroot, "info.virtual", TRUE);*/
    hal_device_set_udi (fakeroot, 
                        "/org/freedesktop/Hal/devices/fakeroot");
    hal_device_store_add (hald_get_gdl (), fakeroot);

so you can see it using lshal or hal-device-manager.

>   What other tips can
> you provide me on porting HAL?  Thanks.
> 

Much of the API that the hal daemon offer is in what properties are
exposed as shown here

 http://freedesktop.org/~david/gnome-vfs-hal-patch2-screenshot.png

The properties are supposed to be documented in the HAL spec at the
website, http://hal.freedesktop.org , but this is a little bit out of
date. I'll promise to update it soon! If you have access to a Linux box
it should be really easy to see the various properties by installing
HAL; there exist packages for a number of distributions; of course the
source tells as well.

I guess that one of the first things to look at is D-BUS, which is the
only non-trivial dependency that HAL has; I'm not sure if this is
already ported to FreeBSD; IIRC there were some issues insofar that the
D-BUS implementation currently uses abstract sockets or something. Once
that D-BUS is working properly on FreeBSD, adding a dummy device as
noted above should be straightforward just to have a checkpoint. Then it
would make sense to get USB devices added and then getting the FreeBSD
HAL implementation to expose the key properties of storage devices such
as block.device and block.mount_point. Then e.g. gnome-volume-manager
and the gnome-vfs hal patch should work without any modification.

Regarding implementing the core HAL stuff on FreeBSD it's important to
note that one of the things we try to achieve is marrying bus devices
with class devices, I've written a bit about that here

 http://freedesktop.org/pipermail/hal/2004-May/000128.html

when answering how feasible it would be to implement HAL on Linux 2.4 -
I'm quite sure it's difficult to do on Linux 2.4, so I'm curious on how
much effort is required on FreeBSD. 

I actually tried to google a bit on how to e.g. find out what the block
device for a USB key is on FreeBSD but found that one of the solutions
posted required looking in log files, just like on Linux 2.4 (though
there exist a number of shell scripts for doing it on Linux 2.4). Here
it is 

 http://ezine.daemonnews.org/200305/cfmount.html

But again I don't know a lot about FreeBSD, however I'm very interested
in helping out porting HAL. Should I install FreeBSD 4.x or 5.x? :-)

Cheers,
David





_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list