Subject: Re: Bitfields and kernel
To: Brett Lymn <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 09/29/1999 22:08:52
On Thu, 30 Sep 1999, Brett Lymn wrote:
# According to der Mouse:
# >The biggest problem with this, aside from the nonportability various
# >people have commented on, is that it becomes impossible to manipulate
# >multiple bits at the same time. This can be important for setting and
# >clearing bits and can be useful when testing bits.
# *shrug* just union the bit fields with an appropriate sized unsigned
That seems like a lot of work for a little gain. I was going to say
it was messy, but not really.
If you're going to use a union, you've just added another layer
in which you need to use a . or a ->; that seems pretty silly to me.
gcc does enums correctly, does it not? Why not use enums and some
macros and be done with it?
(Factually, I used to use macros, but I got to the point where it was
just easier to use raw code, i.e.,
p->p_flags |= (VALUE1|VALUE2) &~ (VALUE3);
# >More important, which is more comfortable for our kernel hackers? For
# >what it's worth, I feel more comfortable with #defines.
I'm a kernel hacker wannabe -- the best I ever did was to tie in
QUOTA with the chown() ability for non-super-users, back before
POSIX, much less POSIX_CHOWN_RESTRICTED, entered the scene.
[And I twiddled some kernel messages for fun, but that doesn't
really count, either.]
[[and here I am with the SunOS source for an Antares 4-port
Sbus card and not quite sure how to proceed. Hah.]]
# I prefer bit fields :-)
I thought they were kinda neeto when I first discovered them, but
unless you've got a processor that handles them intrinsically (and
a compiler to make use of it), they use more cycles than they're
worth. I've come to appreciate #defines/enums, myself.
NetBSD: You can't handle it. (Well, maybe this group could.)