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

[David Howells <dhowells@redhat.com>]

I know it's not precisely what you're asking about, but there are a number of
types I would like to see:

 (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.

     Some arches, x86_64 and ppc64 for example, can do 32-bit atomic ops, so
     we could make the field smaller in some cases.

     We have a *lot* of flags fields in the kernel, so I wonder if we could
     actually save any space.

     I seem to remember that the argument is (or was) that the type must be
     the natural word size of the machine, but how true is that in actuality?

 (2) Differentiate non-BH spinlocks and BH spinlocks by type.

     It seems like you can't mix BH and non-BH ops on a spinlock without
     lockdep barking.  If that's the case, let's make this a compile-time
     check.

 (3) Let's use bool a lot more for boolean values as the compiler might be
     able to make better choices with it.


And whilst we're at it, a function that I'd like to see:

 (1) on_list() in addition to list_empty() (and similar for other list types).

     I know this would be kind of redundant as is would be implemented exactly
     the same as list_empty() - but semantically you're asking a different
     question.

David