Re: [neroden@twcny.rr.com: Re: Re: more evil firmwares found]
@ 11/05/2004 23:58 : wrote Donovan Baarda :
Yeah. I suspect that the complications of convincing the Open Source
world that a binary blob _is_ the "source code" has encouraged hardware
manufacturers to turn their binary blobs into C. This has not helped :-(
not only the complications of convincing, but I think mainly the use of
source-versioning tools, that often dislike binary files... up to a
certain point in time (one, two years ago?) Linus had a
non-binary-file-in-kernel-tarballs policy (so diff/patch works), I don't
know if this continues.
Documentation would definitely help, but I suspect that documentation
will be harder to squeeze out of manufacturers than source. It assumes
they actually have some documentation in a usable form, and not just in
some engineers head and/or scribbled notes. Decent engineers working for
quality companies produce good internal documentation, but I don't know
how many budget hardware manufacturers fall into that category.
Companies that do produce decent internal documentation will consider
the documentation to be more important IP than the source code.
I don't think he meant _complete_ documentation, just documentation in
the fact that the blob is the preferred form for modification.
Actually, I would argue that they are all software. Even the hardware
design is "software". However, the hardware and "burnt" firmware isn't
distributed by Debian, so it's not Debian's problem.
This point has to be beaten with a cluebat in the heads of many people
here: the problem is stuff that is distributed by Debian when it should
not, "as per" the SC, and in some cases, copyrights.
See above for my definition of the "entire firmware". However, it would
be fairly common for chipset and state-machine based designs to have a
single hand coded hex array and code to load it as the only "software"
provided with the hardware.
One phrase from the copyright holder will suffice in this case:
/*
* the following array is the register's inicialization values;
* we don't touch them, and you souldn't, also.
*/
(attention humour-impaired readers: everything past the semicolon is a joke)
I have to assume that the 'microcode' in the r128 and radeon drivers is, in
fact, microcode.
I would tend to agree, except I wouldn't bet on it. From ATI's point of
view it would make sense to build development assemblers and compilers
for their "high level" instruction set. However, it might be easier to
just hand code the microcode once for each chipset to implement that
"high level" instruction set. The overhead of building microcode
development tool-sets might not be worth it, particularly if each
chipset is so different the tool-set can't be re-used between them.
I think he meant "what we have in the r128 and radeon drivers is
probably software compiled from some form of assembly, Cg, or something
like that". And I agree. Even if the chipset is so different, if there
is source assembly (comments a bonus) or something like Cg (better yet
and with comments, just heaven), it could go into contrib... and
eventually into main (when someone writes a tool that makes this possible).
Often they don't know; all they have
is the same source you do, and the incomprehensible scribbled
calculations of the engineer who wrote it were either filed in the
trash, or are buried in a working file somewhere with configuration
management.
Well, that's OK, of course.
Well... from a good design practices point of view it is totally evil
:-)
Evil, but... it's the praxis in many shops. I witnessed this, too.
More 2 c's... :-(
Peace and long live,
--
br,M
Reply to: