On Tue, 2010-06-01 at 20:20 -0400, Matthias Clasen wrote: > On Tue, Jun 1, 2010 at 7:38 PM, Vincent Untz <vuntz gnome org> wrote: > > Hi, > > > > > + Since we don't have HAL anymore, we need to clearly document what > > code needs to be ported to various platforms. See the wiki page: > > http://live.gnome.org/action/diff/TwoPointThirtyone/PortabilityMatrix > > Just to emphasize this point: it is a wiki page, and we would > appreciate contributions to this table, in particular from people who > might have first-hand experience in getting GNOME built on non-linux > systems. It's good you started this because I was going to comment. The state of things on FreeBSD is as follows: GIO : volume monitoring : works because it uses hal g-d-u : does not work as it requires udev udisks : does not work as it requires udev upower : Ported and working cheese : Works now because I back-ported hal support GTK+ : Both CUPS and lpr printing work in FreeBSD g-p-m : Works with upower gnome-media : Works with pulse gnome-bluetooth : does not work as it requires bluez The big problem is clearly udev. Last I looked, it was very Linux-centric (i.e. a very thin wrapper on sysfs which FreeBSD does not have). The reason upower came to be on FreeBSD was that someone abstracted the backends, and made it easy to plug in new ones. Say what you will about hal, it had a spec that made it relatively easy to port from platform to platform with some amount of consistency. In FreeBSD we have a device tree which provides a hierarchy of device nodes, but doesn't give too many details about each device. For that, we have to dig a bit deeper (often times requiring root access). For hal, that wasn't a big deal. We could separate privileges, and things worked. I guess udev is started as root by dbus, so that shouldn't be a big deal. What is a big deal is deciding what device nodes to report and what properties of those nodes to advertise. If there was an abstracted backend API for udev, and a list of common subsystems/devices/properties required, I think it would be possible to integrate the work done in hal. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome FreeBSD org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome
Attachment:
signature.asc
Description: This is a digitally signed message part