Date: Mon, 12 Jul 2004 16:22:59 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: green@freebsd.org Cc: phk@phk.freebsd.dk Subject: Re: userland firmware loader? Message-ID: <20040712.162259.21927670.imp@bsdimp.com> In-Reply-To: <20040710151647.GI1626@green.homeunix.org> References: <20040709232355.GB1626@green.homeunix.org> <1420.1089448716@critter.freebsd.dk> <20040710151647.GI1626@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040710151647.GI1626@green.homeunix.org>
Brian Fundakowski Feldman <green@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040712.162259.21927670.imp>