lkml.org 
[lkml]   [2008]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] bitfields API
On Thu, Aug 28, 2008 at 08:46:43PM +0200, Vegard Nossum wrote:
> On Thu, Aug 28, 2008 at 8:40 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > On Thu, Aug 28, 2008 at 08:32:23PM +0200, Vegard Nossum wrote:
> >> How do you feel about this patch? It's all about making kmemcheck more
> >> useful... and not much else. Does it have any chance of entering the
> >> kernel along with kmemcheck (when/if that happens)?
> >
> > DEFINE_BITFIELD is horrible.
> >
> >> @@ -285,11 +286,12 @@ struct sk_buff {
> >> };
> >> };
> >> __u32 priority;
> >> - __u8 local_df:1,
> >> + DEFINE_BITFIELD(__u8, flags1,
> >> + local_df:1,
> >> cloned:1,
> >> ip_summed:2,
> >> nohdr:1,
> >> - nfctinfo:3;
> >> + nfctinfo:3);
> >> __u8 pkt_type:3,
> >> fclone:2,
> >> ipvs_property:1,
>
> Ok, that's constructive :-P
>
> Can we skip the type and always assume that it should be __u8/uint8_t?

Of course, no.

> I read somewhere that bitfields should anyway always be 1 byte wide if
> the bitfield should be "portable".

It should be signed int or unsigned int for maximum portability.

> Would it help (to make this less
> horrible) to omit the type declaration and have just the bitfield
> members as arguments to the macro?

Or you can parse instruction stream a bit more.



\
 
 \ /
  Last update: 2008-08-28 21:07    [W:0.064 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site