Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Nov 2005 11:39:38 -0700
From:      Scott Long <scottl@samsco.org>
To:        Warner Losh <imp@bsdimp.com>
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
Message-ID:  <4382146A.9000006@samsco.org>
In-Reply-To: <20051121.112724.41676073.imp@bsdimp.com>
References:  <4381FEDF.7080607@root.org>	<00ff01c5eec3$3b0e6640$0300a8c0@COMETE>	<43820C0C.6000001@samsco.org> <20051121.112724.41676073.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4382146A.9000006>