[Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel
David Howells
dhowells at redhat.com
Thu Jul 21 15:05:25 UTC 2016
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
More information about the Ksummit-discuss
mailing list