Re: [Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel

[Guenter Roeck <linux@roeck-us.net>]

On Fri, Jul 22, 2016 at 11:19:46AM -0700, Dmitry Torokhov wrote:
> On Fri, Jul 22, 2016 at 08:03:06AM +0100, David Howells wrote:
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 
> > > >  (1) A 'bits' and maybe a 'bits64' type.  Currently you have to use unsigned
> > > >      long when you want to deploy a flags field with which you're going to use
> > > >      test_bit() and co. - but this typically wastes 32 bits on a 64-bit arch
> > > >      because you can't use bits 32-63 as they might not exist.
> > > 
> > > What is wrong with using DECLARE_BITMAP()? It will allocate exactly as
> > > many unsigned longs
> > 
> > You missed my point.  *unsigned long* is the issue.  The majority of the time
> > that wastes 32 bits on a 64-bit machine - especially when we don't need that
> > many flags.  On some 64-bit arches we could use unsigned int instead.
> 
> I was responding to your statement where you were saying you could not
> use bits 32 - 63 as they might not exist. If you have so many bits then
> DECLARE_BITMAP is useful. Otherwise we can simply use u{8|16|32} and
> BIT() macro.
> 
... unless one needs to statically initialize the bitmap. At least for my part
I have not been able to find a means to initialize a static bitmap with anything
but 0. Effectively this means that such bitmaps have to use u{8|16|32|64}
and thus can not use any of the bitmap operations, or one has to use unsigned
long and thus can only use 32 bit.

Guenter