On Thu, Aug 31, 2006 at 02:43:59PM -0700, Thomas Bushnell BSG wrote: > Sven Luther <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
