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

[Hannes Reinecke <hare@suse.com>]

On 07/22/2016 08:14 AM, Julia Lawall wrote:
> 
> 
> On Fri, 22 Jul 2016, Hannes Reinecke wrote:
> 
>> On 07/21/2016 05:05 PM, David Howells wrote:
>>> 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.
>>
>> Actually that's one thing on my long-term to-do list: stricter range
>> checking for kernel functions.
>> enums are an obvious way to address that,
> 
> In C, enums are ints.  Is there a Gcc option that checks them?  For
> example, the following program compiles fine with -Wall:
> 
> enum one {ONE=1, TWO=2, THREE=3};
> enum two {ONEX=7, TWOX=8, THREEX=9};
> 
> int f (int x) {
>   enum one o = ONE;
>   enum two t = THREEX;
>   if (x) o = t; else t = o;
>   return 0;
> }
> 
>From what I know GCC only checks enums if they are used in a switch()
statement. Other types are not checked.

>> but there is a broad range of
>> functions which return an errno value without ever exhausting the entire
>> errno range.
> 
> I guess that almost all functions return only a few possible error codes?

Precisely. If we had a way of specifying "the return value is an errno
with the possible values '0', '-EIO', and '-EINVAL'" that would be
_so_ cool.

> But only a few call sites check the values either.
> 
I know. But this is primarily because the caller itself isn't quite sure
which values to expect.
ATM one has to rely on the function documentation if existing.
And even that might be outdated.

> In terms of collecting this information, one would quickly run into
> function pointers, but that would probably not be a insurmountable
> obstacle.
> 
But then even the functions pointed to could / should use this syntax,
so we would have a set of all possible return codes.
The important bit here is that we would be able to check
programmatically which values can be returned.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)