Re: kernel firmwares: GR proposal
On Thu, Aug 31, 2006 at 03:03:13PM -0700, Thomas Bushnell BSG wrote:
> 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".
Microcode does run in a lower level of the cpu than the main code, as thus you
could see it as a program (actually a set of small programs probably), which
are uploaded to the main cpu in order to make it work as expected.
I think the main difference here is that it doesn't run in the same
place/location/whatever as the main code, which will exclude stuff like the
soft-ADSL binary only library ofthe unicorn driver.
> > 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.
Well, since i explicitly mentioned microcode above, i would be right and you
wrong :)
> > Bah. Remember, common sense and good faith :)
>
> We have now at least *eight* different definitions that have been
Ah, now, notice that i prefaced my definition as :
For the purpose of this GR, we consider ...
(or some paraphrase of it), so you cannot put in the same sack this definition
and the other definitions you mentioned.
> 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.
Sure we are, it is just you which has not yet understood it :)
> > 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.
Err, sorry, but i gave a pretty concrete definition here, which can be used to
go through every bit of sourceless binary blob in the kernel source tree, and
unequivocably classify it one way or another. What more do you want ?
So, please come up with an actual case of the above definition not being
enough for classification, and once you find something such, we will adapt the
definition to clarify its classification.
Friendly,
Sven Luther
Reply to: