Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
Due to return -ENOPATCH, don't CC lkml please.
Hallo,
On Tue, Aug 29, 2006 at 06:30:25PM +0200, Michael Buesch wrote:
> On Tuesday 29 August 2006 04:15, Oleg Verych wrote:
> > James Bottomley wrote:
> > > On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> > >
> > >>request_firmware() is dead also.
> > >>YMMV, but three years, and there are still big chunks of binary in kernel.
> > >>And please don't add new useless info _in_ it.
> > >
> > >
> > > I er don't think so.
> > >
> > Hell, what can be as easy as this:
> > ,-
> > |modprobe $drv
> > |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
> > `-
> > where /dev/blobs is similar to /dev/port or even /dev/null char device.
> > if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,
>
> Please tell me how this is going to work, if we don't
> know which firmware (version) is needed before be actually
> initialize the device?
>
be = we, right ?
OK. I don't know who i'm going to explain my idea, programmer or user, but.
First of all two refs:
My own words: <http://permalink.gmane.org/gmane.linux.kernel/435955>
Just have read: <http://www.sabi.co.uk/Notes/linuxPragmaCoding.html>
If you see my point, i'm having (system)programmers and users(admins).
And this two completely opposite domains are meeting here, in a tiny task as
firmware uploading. Situation even harder: kernel developers mainly are not
bare-metal or firmware system programmers.
So. You are seeing chardev-like interface to kernel, and asking how this is
suppose to work ? Remember that ACPI description from mr. Linus ? Yes,
"As a someone who's spent a lot if his life doing contract/consulting
work, I've spent a lot of time breaking the bad habits of the junior
programmers assigned to work with me on various jobs. The most
valuable lesson I was ever able to teach them is that when you uncover
a problem, see if the design needs fixing before you barge in and
start trying to fix the code."
-- rbsjrx <Bob.Stout@rftrax.com>
That interface is for main etab-library (external text and binary
or external tab (with LSD ;)) of all kinds of hardware config. stuff:
USB id, PCI id, CPU microcode, GPU microcode, all kinds of firmwares.
This etab-library is a simple list of
* driver-name
* acquired-ext-config
items. When driver is registered (module or in-kernel) it places an order
for etab, what it needs. Admin(user) knowing its hardware (hotplug or not)
compose a directory of etab-files with all info for every "driver-name".
Note, that linux isn't a microkernel, and adding whatever feature in
running kernel isn't possible without patch/config/make. And all this is
mostly done by distributions, isn't it ?
Thus we have all info admin wants and kernel(drivers) needs.
Bounds, sizes, lifetimes of in-kernel etabs is a set, to workout.
Unless you need all this on boot time, use chardev-like interface,
otherwise use kernel loader, by adding cpio-etab image to "initrd="
bootloader option ([1] monolithic kernel), or initramfs (initrd fs) + chardev
in case of moduled one [2], [3] usage is what you've saw in my prev. message.
Then, let me take your example:
> The ipw needs the firmware on insmod time
[1], [2], [3]
> (in contrast to bcm43xx for example, which needs it on ifconfig up time).
[1], [2], [3]
Handling orders, etab-library itself is an internal part, like
/dev/zero or /dev/null. Implementation seems small and obvious...
Your thoughts ?
--
-o--=O`C /. .\ (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)
Reply to: