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 <[EMAIL PROTECTED]> 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
