Re: kernel firmwares: GR proposal
Sven Luther <sven.luther@wanadoo.fr> writes:
> Nope, i am not sure we have such microcode in the kernel tree. It certainly
> fits the same category as the rest of the stuff, and i think the above
> identifies perfectly which firmware blobs we are speakign about.
Huh? Microcode for the main processor doesn't fit anything like the
"rest of the stuff". The rest of the stuff you described as:
1) Programs or register dumps or fpga config files
2) Which are uploaded to a peripheral processor
3) And are part of a linux kernel driver.
Now of course that's not a definition of firmware; it's just a
definition of what you want to grant a Social Contract exception to.
Microcode for the main processor does not match (2) or (3). So no,
there is no obvious likeness between microcode for the main processor
and the "rest of the stuff".
> Use the above as guidelines to classify any such blobs you find, it is
> decidable enough, so i think there is no doubt on this.
I can already see that if we had used your definition, and main
processor microcode turned out to be present in Linux, you would start
insisting that it meets your definition, and I would insist that it
does not. Claiming there is no doubt is hardly likely then.
> Bah. Remember, common sense and good faith :)
We have now at least *eight* different definitions that have been
bandied about. Good faith maybe, but common sense is that you people
are not yet really sure *what* you are talking about, and I tend to
agree.
> Maybe we could clarify this one a bit, but i think it is pretty clear what is
> involved here, and in particular it doesn't suffer from the
> firmware-are-not-programs syndrom, and thus description is less important.
It isn't the least bit clear to me. The fact that a request for
clarity has been met by vague "we all know what we are talking about"
and now eight inconsistent definitions suggest that it isn't clear to
anyone what it is really about.
Thomas
Reply to: