Date: Thu, 07 Feb 2008 16:30:02 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcus@marcuscom.com Cc: avg@icyb.net.ua, freebsd-gnome@freebsd.org, freebsd-arch@freebsd.org Subject: Re: HAL/freebsd architecture Message-ID: <20080207.163002.1649769344.imp@bsdimp.com> In-Reply-To: <1202065383.59813.40.camel@shumai.marcuscom.com> References: <479F1713.2030705@icyb.net.ua> <1202065383.59813.40.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1202065383.59813.40.camel@shumai.marcuscom.com>
Joe Marcus Clarke <marcus@marcuscom.com> writes:
:
: 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.
What's needed here? I don't think I've been poked and devinfo
interface should give you the device tree...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080207.163002.1649769344.imp>