Re: New module decisions for 3.0

[David Zeuthen <zeuthen gmail com>]

Hey,

On Tue, Jun 1, 2010 at 8:48 PM, Joe Marcus Clarke <marcus freebsd org> wrote:
> 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

GIO also works even if you don't have HAL because GIO ships with a
GUnixVolumeMonitor that works on most Unices even the really obscure
ones.

Btw, you could also write a GVolumeMonitor implementation that uses
FreeBSD specific APIs to enumerate drives, volumes and mounts.

> g-d-u : does not work as it requires udev

Actually, this should be "does not work as it requires udisks". The
gdu codebase is very careful about not using Linux specific API and
even not assuming the udisks daemon is running on the same host - this
is why e.g. management of remote hosts

 http://people.freedesktop.org/~david/gdu-multiple-servers.png

just works. IOW, if you have something implementing the udisks API,
then gdu and palimpsest will just work.

> udisks : does not work as it requires udev

Actually udisks is designed in a way so it isn't dependent on Linux
and so it can be ported to, say, FreeBSD or Solaris. Honestly, it's
this way mostly because Linux itself is a very fluid and moving
target.... Anyway, the docs clearly shows this

http://hal.freedesktop.org/docs/udisks/

e.g. Linux specific features are clearly marked as such; IOW there's
no attempts to "abstract" what, say, RAID means and then hope that the
Linux implementation (using MD RAID) and the FreeBSD implementation
(using Vinum) agrees and both fit a common API. Because I don't think
that's ever going to work (the best we can hope for is that both OS'es
have a notion of block devices).

The udisks codebase however isn't currently set up so it's easy to
"port" the udisks codebase to, say, FreeBSD. But I'm planning to at
least make that easier, I'm already busy porting it to use GDBus and a
big part of that work is cleaning up the separation between the core
service and kernel-OS-specific code.

> 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.

Having backends for udev just doesn't make sense because udev (or
sysfs) itself isn't a spec or an abstraction. It's the raw Linux
device management API - in a very real sense you are dealing with
internal kernel data structures when you peek and poke around in sysfs
either directly or indirectly via libudev / libgudev1. So it might be
easier just to run Linux instead of trying to emulate it....

     David