"Mark Brown" <broonie@sirena.org.uk> 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 coding practice.
So why do drivers get to have sequences of bytes without any rational explanation attached?