HAL/freebsd architecture

Joe Marcus Clarke marcus at marcuscom.com
Sun Feb 3 11:02:48 PST 2008


On Tue, 2008-01-29 at 14:07 +0200, Andriy Gapon wrote:
> This is not a concrete suggestion and I can not volunteer to write any
> code yet (unfortunately).
> 
> Recently I played a little bit with DesktopBSD live CD and liked some
> add-on software provided there and some implementation approaches were
> quite interesting for me too.
> 
> Just in case, the tools can be found in sysutils/desktopbsd-tools and
> there is a FAQ page on using them in "plain" FreeBSD:
> http://desktopbsd.net/wiki/doku.php?id=doc:desktopbsd_tools_in_freebsd
> 
> This got me thinking: maybe we could also apply the same approach as
> used for dbsd-hwnotify to HAL/FreeBSD. I.e. hald could do initial
> querying of devices and then just wait for notification from devd about
> any changes.
> 
> This, of course, would require some changes to the base system, but I
> think that these would be useful for many more applications than just hald.
> 
> Some things that come to mind first: "forward" instruction to devd.conf
> to execute some action for all events in addition to any event-specific
> actions. This is so that we could preserve current devd functionality
> but also allow to delegate some decisions to other software.
> 
> I think that this way we could get a lot of current hald functionality
> for free, without the special probing/polling routines that have to
> written at present.
> But this would probably mean some additional changes in kernel-land. For
> example, there are complaints now that CD-ROM drivers do not
> automatically notice media removal/change and, for instance, do not
> update GEOM_LABEL information [*]. This is important for HAL
> functionality too. So, media checking/polling would probably have to go
> to the CD-ROM drivers.
> But, as I said earlier, this would probably be a universal good - we
> could kill several birds with one stone.
> 
> To summarize: most of what FreeBSD hald currently does in userland is
> either already done in kernel as well or it better be done in kernel.
> hald should just mostly listen to notifications coming from kernel. Most
> likely this is best done via devd. Such approaches, of course, would
> require changes to pieces of kernel and to devd.

hald already listens to devd for as many events as it can.  I agree that
some information is better tracked in the kernel, but devd is not the
right outlet for everything (we still need to build a device tree when
hald starts).  I have been poking a few kernel/driver developers to
expose more information via sysctl as this is a safe way of obtaining
hardware data without needing elevated privileges, or access the devices
directly.

Linux's hald backend relies heavily on sysfs, and ours on sysctl and
devinfo.  The more we can expose to these two interfaces, the better,
and more robust hal will be on FreeBSD.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080203/2986d1bd/attachment.pgp


More information about the freebsd-arch mailing list