Date: Thu, 07 Feb 2008 20:02:59 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: avg@icyb.net.ua, freebsd-gnome@freebsd.org, freebsd-arch@freebsd.org Subject: Re: HAL/freebsd architecture Message-ID: <1202432579.94347.9.camel@shumai.marcuscom.com> In-Reply-To: <20080207.163002.1649769344.imp@bsdimp.com> References: <479F1713.2030705@icyb.net.ua> <1202065383.59813.40.camel@shumai.marcuscom.com> <20080207.163002.1649769344.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-V3qPcoFAsmWqVMPszcuE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-02-07 at 16:30 -0700, M. Warner Losh wrote: > In message: <1202065383.59813.40.camel@shumai.marcuscom.com> > Joe Marcus Clarke <marcus@marcuscom.com> writes: > :=20 > : 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 an= y > : > code yet (unfortunately). > : >=20 > : > Recently I played a little bit with DesktopBSD live CD and liked some > : > add-on software provided there and some implementation approaches wer= e > : > quite interesting for me too. > : >=20 > : > 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=3Ddoc:desktopbsd_tools_in_free= bsd > : >=20 > : > 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 abo= ut > : > any changes. > : >=20 > : > 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. > : >=20 > : > Some things that come to mind first: "forward" instruction to devd.co= nf > : > to execute some action for all events in addition to any event-specif= ic > : > actions. This is so that we could preserve current devd functionality > : > but also allow to delegate some decisions to other software. > : >=20 > : > I think that this way we could get a lot of current hald functionalit= y > : > 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. > : >=20 > : > 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. M= ost > : > likely this is best done via devd. Such approaches, of course, would > : > require changes to pieces of kernel and to devd. > :=20 > : hald already listens to devd for as many events as it can. I agree tha= t > : 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 device= s > : directly. >=20 > What's needed here? I don't think I've been poked and devinfo > interface should give you the device tree... devinfo does give us the tree, and we use it. Some of the things I've asked developers include extending the ldev driver (luigi's Linux device driver wrapper) to expose the device class via a sysctl, and adding version and driver type sysctls for our DRM driver (anholt). Another sysctl that would be nice to have is one that gives the actual /dev device node (if applicable) for each device. Some of these are obvious, but others are not. As I work through the HAL spec (http://www.marcuscom.com/hal-spec/hal-spec.html), and find areas where we cannot easily map properties, I try to notify developers. One area I haven't yet pursued is firewire. We cannot easily build firewire nodes in the HAL tree, but this is not a high priority. Another area where I think we could use some improvement is the printer area. Currently, I know of know way to fill in the printer properties using sysctl, devinfo, or any ioctl APIs. This could add some benefit as there are a few apps which make use of HAL's printer support to auto-detect printers. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-V3qPcoFAsmWqVMPszcuE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkerqkIACgkQb2iPiv4Uz4cyDQCeJxqb4T3DsQgkiVVXC8pMJ6Ne j8gAn29+r/VQP7V1MIzacrgrbvEdqkts =XnqB -----END PGP SIGNATURE----- --=-V3qPcoFAsmWqVMPszcuE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1202432579.94347.9.camel>