Re: kernel firmwares: GR proposal

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Aug 31, 2006 at 05:33:42PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> 
> > Well, it would be part of a driver aimed at driving the main cpu, yes, it is
> > not a peripheral processor, but the role played by the microcode is peripheral
> > to the main flow of the kernel code.
> 
> Do you really not see why this is hopelessly vague?  

Only if you chose to make it vague.

> >> Are you now saying that anything uploaded to the main cpu should be
> >> excluded from the DFSG?  Wow.
> >
> > You did notice where i explained that microcode is loaded into a lower level
> > of the cpu, and not in the same level as the code normally runs, right ? Why
> > do you then deliberately misinterpret it in the above.
> 
> What is the "lower level" and why should our principles depend on
> this?  
> 
> > In particular, when a normal program is loaded, the main processing unit of
> > the cpu has a program counter which loads instructions into the cpu, and those
> > are then executed and so on.
> 
> Guess what: microcode is executed with a program counter which loads
> instructions into the CPU gates.

Indeed, but it is not the same program counter used by the main program.

> The difference is that microcode is stored in very fast memory in the
> processor chip itself and that the "main code" is stored in regular
> DRAM.  So now we're back to one of your previous definitions: that
> firmware is defined by what kind of memory it is stored in when it is
> executed. 

Indeed, but the microcode and the actual program are run on two separate
instruction set. The microcode kind of emulating the instruction set for the
actual instruction set used.

> > The cpu microcode doesn't follow this selsame route, and as thus, are loaded
> > into a peripheral part of the cpu.
> 
> Actually, microcode is normally loaded into the *central* part of the CPU.

bah, word play, but in any case it is not the same part as the main program.

> > Sure, but we are speaking clasification of the the firmware blobs. We all
> > agree that those who are sourceless and not just plain register dumps are
> > non-free.
> 
> Really?  Steve Langasek thinks they aren't programs at all, and

Indeed, didn't we both agree he was wrong on this ? 

> therefore they are free if they can be distributed, since, not being
> programs, they don't need source.  I find this crazy of course: the
> question is whether they *have* source, and everyone agrees that they
> do. 

So ? 

> > Bah, you are changing topic because you don't want to admit that my
> > classification proposal of what we want to describe as firmware in the context
> > of this GR is indeed enough to remove all doubts about what we are speaking
> > about.
> 
> You keep changing the definition, so please don't speak of a
> "classification proposal" in the singular.  Which one do you want me
> to address?  Please write the whole thing down, in the language you
> think it should be in the GR.  I'm not interested in looking at a

I already did. Well, not being native english speaker, and all, maybe it is
not as polished as it could, but i think the definition is complete enough to
define clearly what is being considered in *THIS* GR (and not Steve's or
whoever's).

> vaguely stated "you know what I mean" where I have to figure out which
> of your statements to put together and how.  Just let me know, in the
> form you think is satisfactory.

I already did so, but let's try again :

  We consider for the purpose of this GR, firmware to be :

    - register dumps, actual program code and FPGA code, which is uploaded to
      a peripheral processor.

    - microcode which is uploaded to the main cpu in order, and whose purpose
      it is to emulate the main instruction set of the cpu, as well as any
      secondary unit present on the main cpu die (altough those can be
      considered as peripheral processors in the case of SoC cpus).

  In all these cases, the firmware in question is run in a separate hardware
  space than the main program, here the linux kernel, and whose sole
  interaction between the device running said firmware and the kernel drivers
  for the device are a well defined interface.

  In the linux kernel case, those binary-only firmware are usually in the form
  of a char array containing an hexadecimal representation of the binary in
  question, but other equivalent representations may also be used.

  This clearly exludes any kind of library or object files, which are linked
  with the main program and running in the same processor space, beyond
  information concerning their placement in memory and size, and eventually
  some kind of checksum.

There, i think this covers it and sumarize all i have said on the topic. The
GR then continues to declare that those are programs we need source for to be
DFSG compliant, but in order to get etch out we are going to waive that source
requirement for exactly those files.

Friendly,

Sven Luther