Porting HAL to FreeBSD

[David Zeuthen]

On Sat, 2004-06-19 at 16:37 -0400, Joe Marcus Clarke wrote: 
> > 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.
> 
> So DBUS is also platform-specific?  I was under the impression it was
> more generic.  We had a guy working on porting DBUS to FreeBSD, but I
> haven't heard from him in a long time, and I'm not sure on the status of
> that.
> 

The goal of DBUS is to work on a very large number of OS'es, but due to
authentication issues (DBUS sports a quite flexible and extensible
security model) I think it only currently works on Linux since the
current authentication mechanism relies on credentials passing stuff on
sockets which is fairly non-portable as far as I understand; there were
some recent discussion here

 http://freedesktop.org/pipermail/dbus/2004-May/001093.html

and some here

 https://listman.redhat.com/archives/message-bus-list/2003-October/msg00075.html

However, DBUS has a dbus-sysdeps.[ch] files to abstract such details.

> FreeBSD has userland hooks for getting certain device events.  On 4.X,
> we have a usbd that can recognize when USB devices are attached, and
> spawn programs (e.g. moused) to handle certain drivers.  On 5.X, we have
> a more generic devd which handles similar attachment events, but does so
> more a plethora of other devices (e.g. PCMCIA devices).
> 

Very nice.

> > 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)");
> 
> This property would not exist on FreeBSD.  I assume that one would just
> ignore this, or create a new, FreeBSDs-specific, property if warranted?

Right; the linux.sysfs_path stuff is required for every device on Linux
such that applications and libraries using HAL can find more info on the
device. I suppose that a similar construct would be used on FreeBSD.
I've tried in HAL to separate Linux specific stuff out; for instance for
USB devices the property usb.linux.device_number gives a Linux-specific
number for the device unique on a bus so e.g. libgphoto2 can find the
device to interact with (the thinking is that a photo application simply
passes a HAL UDI to libgphoto2). Again this is probably something we
also want for FreeBSD.

> > 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.
> 
> Yeah, USB would probably be easiest, but I fear 4.X might be a lost
> cause.  D-BUS and/or hald would have to run as root to get some of this
> information as it would need to open device nodes.
> 

The system message bus from D-BUS is designed to run as a unprivileged
user (it just passes messages around) and on Linux the HAL daemon is
designed to run as root as it needs to open devices nodes to read vital
product data and also because it invokes callouts when devices are added
and/or removed. One example of a callout is the update-fstab.sh shell
script (which is shipped with HAL) to add and remove entries in /etc/
fstab for e.g. USB keydisks; this obviously require root. I suppose this
can be reused with little change for 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
> 
> This is doable, but not in the most straight-forward manner.  You can
> use ioctls on the various USB controller devices, and get a list of USB
> devices attached.  If you see a umass device, you know you have a
> harddrive.  You can then walk through all of the SCSI CAM attached
> devices (all USB disks are CAM devices) until you find a device on the
> umassX controller where X is the unit number seen from your USB ioctl
> work.
> 
> A quick command line look at this would be to use "usbdevs -d" and
> "camcontrol devlist".  Note: CAM requires read-write access to the
> pass(4) devices.  This is something most GNOME users have setup anyway
> because n-c-b and sound-juicer require this as well.

Sounds good it's doable!

> > 
> > 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? :-)
> 
> That would be great!  I think effort should be concentrated on 5.X
> (specifically 5-CURRENT, but 5.2.1-RELEASE would be good, too).  The
> biggest advantage to 5.X is the new devinfo(3) functions that provide a
> device tree rooted at the main nexus.  It lists devices attached as well
> as their I/O ports and IRQs (where appropriate).  You can see what
> devinfo can provide by running devinfo -r -v on a FreeBSD 5.X machine.
> 
> My first step will be looking into D-BUS.  I'll also try to drum up some
> more help from my team.  Thanks for your invaluable input.
> 

I'm downloading the 5.2.1 ISO's right now :-)

Many thanks,
David



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