Linus Torvalds wrote:
quoted text
> 
> On Tue, 15 Jul 2008, Marcel Holtmann wrote:
>> you don't have to. We extend udev once and then it will always work.
> 
> Umm. The thing is, people running new kernels with old user land is not 
> just supposed to work, it's _really_ supposed to work.
> 
> It's what I do. Something that breaks that has to have damn good reasons 
> to break it.
> 
> So I do not disagree with Jeff on that point _at_all_. I'm in violent 
> agreement with Jeff on the fact that we should not require system updates 
> for the kernel to do the right thing.
> 
> The thing I disagree with Jeff on is that he then seems to turn that into 
> something very negative ("let's not separate the firmware at all").

How many times do I have to say you misunderstand?

I'm happy with separating the firmware at the source code level.  I 
never objected to that.

All I want is the _option_ to compile firmware into a module.  We are 
talking about compiled output, here.

That _option_ has the desireable properties of

* working on older userland, even with DavidW's tg3 and scsi patches

* retaining an option several kernel hackers and users find useful

* permitting use of 2.6.27 without _immediately_ having to fix stuff


quoted text
> And I'd much rather just fix it. And that means that if people can point 
> to udevd's that get confused - or lack of udevd's entirely - both of which 
> sound very likely to me, then we should have a graceful fallback position.
> 
> And just supporting the notion of loading the firmware directly sounds 
> like an obvious such case. It may not be the _only_ solution, for example, 
> which is why I'd actually like to see people point to the _actual_ 
> reported problems.
> 
> IOW, the problems shouldn't a "don't do this" thing. They should be a "ok, 
> that problem happened, we can solve it by doing X".

Stop using strawmen, please.

I never said "don't do that".  Ever.

I said "when you do that, don't remove ability to compile firmware into 
the driver."

And as has been stated repeatedly, the compiling firmware into the 
driver clearly DOES NOT exclude the more flexible, load-from-userland 
request_firmware() model.



To be extremely concrete, firmware-in-module is

	* add Kconfig option (kernel-wide or per-driver, dunno) asking
	  "build firmware into drivers, as before?"

	* tweak build process to build firmware into foo.ko output,
	  probably in a specially marked ELF section

	* get request_firmware() to automatically notice that the
	  MODULE_FIRMWARE() was built into this driver, and to
	  look at the special ELF section for its data

See?  That is not a "don't do that."  That has never been "don't do that."

That is the one major request here, one that enables us to avoid all 
those potential breakages I've been listing, and the many more breakages 
of which I'm unaware.  It enables use of older userlands.

And yes, it enables "weirdos" like me to continue building the firmware 
into the driver, because it has a proven track record of high 
reliability and simplicity.

All without stomping on the flexibility of request_firmware().

	Jeff



--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/