cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h

Scott Long scottl at samsco.org
Mon Nov 21 10:39:42 PST 2005


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


More information about the freebsd-arch mailing list