[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel firmwares: GR proposal

On Thu, Aug 31, 2006 at 02:43:59PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> > No. The "sourceless firmware blobs" mentioned in this GR, are identified as
> > those programs or register dumps or fpga config files, which are uploaded to a
> > peripheral processor, and are part of a linux kernel driver in some way,
> > usually an array of chars or some other binary embedded in a variable kind of
> > things. We could also here include the main processor micro-code, since
> > altough it runs on the same processor, it is not running in the same layer of
> > the processor as the one running normal code.
> Ah, another definition.  It's clear from your "we could also here"
> that you aren't sure whether certain things should count as firmware

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.

> or not.  Do you see now why I might want some specificity before we
> have a vote?  

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.

> Since it's you who wants this GR, may I suggest that you'll need to
> figure out just what you want the GR to say?  I can't tell you what
> you want your own proposal to say. 

Bah. Remember, common sense and good faith :)

> > Does this satisfy you as a definition ? 
> It is a little closer to a resolution that could even be plausibly
> voted on.  (It certainly doesn't satisfy me if you mean that I would

Err, i asked if the definition satisfied you, not if the GR satisfied you :)

> vote for it.)  What satisfies me is simply compliance with our
> existing standards.  But that discussion should happen after the
> secretary announces a discussion period.


> Right now I'm concerned that we don't get disastrously vague
> resolutions into voting.

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.

> > If the above is enough, maybe we could add this or a nicer rewording of it to
> > the GR ? 
> The above includes things like "maybe we could include" and "usually"

:s/We could also here include/We also include here/

As for the "usually an array of char", well. It is either an array of chars
represented in hexadecimal, or some other equivalent form to embed a binary in
C code. I think that is pretty clear, and there are not thousand ways to do

> and the like.  It may be a step closer, but it isn't there until you
> decide what you actually want.

Does this definition satisfy your need to define clearly what is involved now


Sven Luther

Reply to: