From owner-freebsd-arch@FreeBSD.ORG Thu Feb 7 23:30:45 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 21B0716A418; Thu, 7 Feb 2008 23:30:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B756F13C47E; Thu, 7 Feb 2008 23:30:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m17NRIQ5093215; Thu, 7 Feb 2008 16:27:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Feb 2008 16:30:02 -0700 (MST) Message-Id: <20080207.163002.1649769344.imp@bsdimp.com> To: marcus@marcuscom.com From: "M. Warner Losh" In-Reply-To: <1202065383.59813.40.camel@shumai.marcuscom.com> References: <479F1713.2030705@icyb.net.ua> <1202065383.59813.40.camel@shumai.marcuscom.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@icyb.net.ua, 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: Thu, 07 Feb 2008 23:30:45 -0000 In message: <1202065383.59813.40.camel@shumai.marcuscom.com> Joe Marcus Clarke 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