From owner-freebsd-arch@FreeBSD.ORG Sun Feb 3 19:02:48 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8385116A417; Sun, 3 Feb 2008 19:02:48 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 3FCAC13C45A; Sun, 3 Feb 2008 19:02:48 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m13J3DtQ025822; Sun, 3 Feb 2008 14:03:14 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Andriy Gapon In-Reply-To: <479F1713.2030705@icyb.net.ua> References: <479F1713.2030705@icyb.net.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mhX7xp3CcfbY+Pug+38s" Organization: MarcusCom, Inc. Date: Sun, 03 Feb 2008 14:03:03 -0500 Message-Id: <1202065383.59813.40.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on creme-brulee.marcuscom.com Cc: freebsd-gnome@freebsd.org, freebsd-arch@freebsd.org Subject: Re: HAL/freebsd architecture X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 19:02:48 -0000 --=-mhX7xp3CcfbY+Pug+38s Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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). >=20 > 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. >=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_freebsd >=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 about > 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 hal= d. >=20 > 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. >=20 > 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. >=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. 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 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-mhX7xp3CcfbY+Pug+38s 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) iEYEABECAAYFAkemD+YACgkQb2iPiv4Uz4eeegCeK5t/lsFYDWmdmaSggDDuY9BV HIIAoK7mbyhMTmYzCxva5AxFC4k1DAiW =i3XZ -----END PGP SIGNATURE----- --=-mhX7xp3CcfbY+Pug+38s--