Subject: Re: Bitfields and kernel
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/29/1999 10:22:46
[ On Wednesday, September 29, 1999 at 15:31:53 (+1000), Julian Assange wrote: ]
> Subject: Re: Bitfields and kernel
> Well, that's the end of struct ip.
Yeah! :-) Well, no, that would be silly, wouldn't it be.
> The structure of information must be defined somewhere. Without
> bitfields / structs you are defining this structure in a manner
> that spreads it ALL OVER the code that uses it and not in any
> central place. Consequently the structure is redunently defined.
> I shouldn't need to explain to this audience the evils of redundant
I can't agree more! Indeed well thought out data structures that make
the best use of the idioms of the language at hand should always be used
where possible inside a program.
It's only that pesky external data that causes problems. K&P in The
"Practice of Programming" chapter 9 outline several good techniques for
getting portable programs to communicate through portable external data.
(This kind of information was sadly missing even in a primitive form in
the first K&R, though obviously in a young language one has to be
somewhat careful about what one carves in stone! ;-)
Mapping pre-defined external data, such as chip registers into internal
data structures is sometimes best done with bit-fiddling because there's
no need to manipulate that data within the program. Loading all of the
register bits into a bit-field and then storing them again after
changing only one or two of them would be an obvious waste of
programming, especially in a performance sensitive section of a device
Doing the right thing for something like struct ip is trickier because
experience has shown that its handling definitely needs to be optimised
at least to some degree.
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>