Re: New module decisions for 3.0

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:
> >
> 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 Marcus Clarke
FreeBSD GNOME Team      ::      gnome FreeBSD org
FreeNode / #freebsd-gnome

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]