Messages in this thread | | | Date | Thu, 28 Aug 2008 23:05:33 +0400 | From | Alexey Dobriyan <> | Subject | Re: [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.
| |