Re: Linux-libre for Debian Lenny
"Mark Brown" <email@example.com> wrote in message
[🔎] 20090427092413.GA1760@sirena.org.uk">news:[🔎] 20090427092413.GA1760@sirena.org.uk...
On Mon, Apr 27, 2009 at 01:48:27AM +0100, Ben Hutchings wrote:
On Sun, 2009-04-26 at 21:41 +0200, Robert Millan wrote:
> #494120 and #494122.
I disagree with these as the tables in question are easily small enough
to be a plausible preferred form for modification.
Indeed; this is a *very* common way of expressing register values,
especially when working with large numbers of them at once. I've no
idea what Robert believes the preferred form of modification is.
Perhaps some indication of where the heck the numbers came from? Surely
there is some meaning to the numbers. In the original Windows drivers, there
was quite possibly a set of enums for each register with descriptive names.
If not, then somewhere there exists some sort of documentation as to the
meanings of the values. Relevant excerpts really should have been included.
If the values lacked meaning, then the hardware would behave just fine with
all zeros as initalization values. If the values were just arbitrary data
that must be uploaded by default for the hardware to activate, as a
protection against certain types of driver/interface corruption, then that
should be explained in a comment.
For some reason, anywhere but a device driver an opaque sequence of 64 bytes
(or even 16 bytes) without comments explaining what they mean, or where they
come from (ie "This is the standard MD5 seed value") would be considered
unacceptable. Pretty much any time you have a numeric constant in code where
the meaning is not obvious it should be explained in a comment, or even
better, refactored into a symbolic constant. Thats just plain standard
So why do drivers get to have sequences of bytes without any rational