From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:39:42 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 A5B6016A41F for ; Mon, 21 Nov 2005 18:39:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BDC43D4C for ; Mon, 21 Nov 2005 18:39:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALIdcOu021737; Mon, 21 Nov 2005 11:39:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4382146A.9000006@samsco.org> Date: Mon, 21 Nov 2005 11:39:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> <43820C0C.6000001@samsco.org> <20051121.112724.41676073.imp@bsdimp.com> In-Reply-To: <20051121.112724.41676073.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org 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:39:42 -0000 Warner Losh wrote: > 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. yes, it passively listens to requests for firmware. > It listens for > events and then runs programs. Excellent! Exactly that is needed! > 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. Maybe you want a program that can on-the-fly patch the wi firmware? > None of the other automatic kldload parts of the kernel need > this. Why is driver firmware any different? Why hack the kernel module loader? > 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? Maybe via some sort of configuration file? I thought that devd had one of those. Guess I'm wrong? > How would concentrating the quirks of all > possible drivers in devd be better than localizing them in the driver > itself? Why put a lot of complexity into a program that corrupts your data when it has a bug? Scott