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