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.
Ok.
> 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
this.
> 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
?
Friendly,
Sven Luther
Reply to: