Date:	Tue, 15 Jul 2008 09:01:08 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	david@...g.hm
cc:	Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>,
	jeff@...zik.org, arjan@...radead.org, akpm@...ux-foundation.org,
	dwmw2@...radead.org, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel,
 use it in more drivers.



On Tue, 15 Jul 2008, david@...g.hm wrote:
> 
> has a standard been defined for how to maintain different versions of firmware
> for different versions of drivers yet?

No. We haven't had that possibility, probably largely because we haven't 
even really had the ability (Davem and Jeff talk about "choice" and how 
request_firmware() supposedly removes it, but they ignore the fact that it 
very much cuts the other way too - request_firmware() _adds_ choice and 
makes it easier for people to try to upgrade firmware without upgrading 
the kernel).

> that was one of the things that was identified in the last flamewar that was
> handwaved away but nothing was defined.

I don't think we can - or want to - define things until we've seen the 
problems and advantages in practice over a longer time.

Do we want a versioning scheme? Probably not - exactly because people may 
well want to update (or downgrade) firmware from vendors independently of 
the kernel.

But maybe people will eventually want some kind of blacklisting scheme 
where the driver can say things like "I know I won't work with versions 
that match this checksum" and cause a nice big warning at load-time.

And I think we can all _imagine_ scenarios in all kinds of possible ways 
for things to work better or fail spectaclarly, and even come up with 
anecdotal evidence where scheme X (out of any number of random variations) 
is the "only possible one to work". I'd argue that we simply don't have 
any realistic way to decide which ones make sense.

For example, we can be in the situation where we have some case where
"only this particular firmware is known to work, and others are known to 
break", and people can still take two totally different mental approaches 
to the problem.

One approach is the "strict control one", where people argue that the 
above problem means that we absolutely *must* have very strict versioning, 
and we just always pair things up exactly.

But the other argument is that firmware is part of hardware, and the 
driver should strive to work with different versions of vendor firmware, 
the same way it should strive to work with different versions of chip 
hardware.

Which one is right?  Probably neither. Sometimes one, sometimes the other, 
and in both cases it should probably not be black-and-white.

IOW, I suspect that in the long run we want to say

  "Ok, there's no way we can support _all_ firmware versions, but on the 
   other hand, we also don't want to force particular versions and not let 
   people experiment.

   So drivers should strive to be flexible, and driver writers should not 
   always just say 'there is only one "blessed" firmware', but on the 
   other hand we cannot require drivers to work around horrible known bugs 
   in firmware when a fixed firmware is available"

but the exact details will have to depend on particular drivers.

And we should obviously have _a_ version of the firmware available with 
the kernel when that is possible. But I'd hate for it to be 1:1 with a 
particular driver version - because at that point it smells of being a 
single work, and if it is more than mere aggregation it's no longer viable 
with most of our firmware (I don't think we have source for more than one 
or two cases).

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

Powered by blists - more mailing lists