From owner-freebsd-arch@FreeBSD.ORG Mon Jul 12 22:24:27 2004 Return-Path: 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 8C4D416A4D6; Mon, 12 Jul 2004 22:24:27 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF30E43D5D; Mon, 12 Jul 2004 22:24:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6CMMwGN040146; Mon, 12 Jul 2004 16:22:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 12 Jul 2004 16:22:59 -0600 (MDT) Message-Id: <20040712.162259.21927670.imp@bsdimp.com> To: green@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040710151647.GI1626@green.homeunix.org> References: <20040709232355.GB1626@green.homeunix.org> <1420.1089448716@critter.freebsd.dk> <20040710151647.GI1626@green.homeunix.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 cc: arch@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: userland firmware loader? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2004 22:24:27 -0000 In message: <20040710151647.GI1626@green.homeunix.org> Brian Fundakowski Feldman writes: : On Sat, Jul 10, 2004 at 10:38:36AM +0200, Poul-Henning Kamp wrote: : > In message <20040709232355.GB1626@green.homeunix.org>, Brian Fundakowski Feldma : > n writes: : > : > >I'm writing a driver that uses a 100KB firmware file and could need to : > >read it again, after initialization, to reset the device (or to load : > >more). Since this device is primarily found in CardBus form, I think : > >it makes a lot of sense to be able to get the firmware file at any time : > >but without specific user intervention. The form factor of the device should be irrelevant to the solution. When do these reset events happen? Do you introduce circular dependencies by requiring an upcall to userland to make things happen? : > >Is this something devd should be doing? : > : > I would advocate a generic interface for retrieving firmware from userland. : : What do you think about using the normal devctl_notify(9) for pushing : out firmware requests, and having a new device method that receives just : a user data pointer and length for it to copyin(9)? It wouldn't be a : very symmetrical API, but it seems like a way that might fit it into the : current structure the easiest, devd and devctl and newbus. I think its a terrible idea. It is against the whole notion that devd just reacts and doesn't hold anything up. If your device needs a reset, then devd gets the message and causes a program to run to load the firmware for the device. Does the driver block until then? What happens if the program never runs? devd reacts to events from the kernel only. It shouldn't be in a critical path or be viewed as an upcall that will return a result. It is a completely optional part of the system. I also think that firmware requests aren't well defined enough to make it into a useful interface. Better to have some way to trigger a module load from inside the driver and use the data, and then unload it when it is done w/o any interaction from userland at all. The firmware module would have a tiny bit of code that would set a pointer to the data structure necessary for the firmware load. Even better would be to allow drivers to read data from mounted file system, but that's difficult to do right now... Warner