From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:30:13 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D9F616A420 for ; Mon, 21 Nov 2005 18:30:13 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E11FD43D4C for ; Mon, 21 Nov 2005 18:30:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIRO9v044301; Mon, 21 Nov 2005 11:27:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:27:24 -0700 (MST) Message-Id: <20051121.112724.41676073.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43820C0C.6000001@samsco.org> References: <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> <43820C0C.6000001@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:27:24 -0700 (MST) Cc: arch@FreeBSD.ORG, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h 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: Mon, 21 Nov 2005 18:30:13 -0000 scottl> Scott Long scottl> I guess my vote would be to have a devd mechanism where the kernel scottl> can ask for a module via a particular key, devd maps the key to a file scottl> via its config file and loads it into kernel space as a KLD, and then scottl> the kernel unloads the KLD when its done with it. For things like isp, scottl> nothing would change, and for iwi you'd get a reliable way of getting scottl> bits into the kernel that doesn't require messing with the VFS layer scottl> or hard-coding knowledge of the filesystem layout into the driver. Apart from my other objections to kld, I really don't like getting devd involved in this. devd is a passive listener. It listens for events and then runs programs. It is not there to interact with the kernel in synchronous manner. Everything is queued and there's deliberately no meachanism for a reply. There's also no reason to have a third party involved to load the module. None of the other automatic kldload parts of the kernel need this. Why is driver firmware any different? You can easily define the interface to be load module "$driver-fw-$type" and the driver can take care of the sprintf to fill in the string. A carefully chosen interface here can help eliminate the extra layers of complexity. How the heck would devd know how to convert the particular key into something meaningful? How would concentrating the quirks of all possible drivers in devd be better than localizing them in the driver itself? Warner