Subject: Bitfields and kernel
To: None <tech-kern@netbsd.org>
From: Brian C. Grayson <bgrayson@marvin.ece.utexas.edu>
List: tech-kern
Date: 09/28/1999 14:09:17
  Is there any inherent reason why using bitfields in the kernel
would be evil?  For example, for some PPC stuff, I'd rather have code
like (off-the-top-of-my-head, so forgive semantic goof-ups):

typedef struct {
  unsigned int reserved0_12:13;
  unsigned int pow:1;
  unsigned int reserved14:1;
  unsigned int ile:1;
  ...
} reg_msr_t;

...
reg_msr_t msr;
...
msr.pow = 1;
msr.ile = 0;

  Currently, these are done with #define's.  I see that some
archs use bitfields for FP and page-table stuff, so there's at
least some precedence for it.

  IMHO, using bitfields is easier to maintain and understand, and
less prone to errors.  However, I don't know if there are
portability problems with it.  Someone at work claims that not
all compilers do bitfields all that well, but it looks like gcc
does.  But gcc isn't the only compiler we care about.

  TIA.

  Brian