lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct
Ingo Molnar wrote:
>>>>> That cpumask[] should probably be cpumask[0], to document the
>>>>> aliasing to ->span and ->cpus properly.
>>>> If the comment wasn't sufficient documentation, I don't think that
>>>> would help :(
>>> It's a visual helper: it matches up with how we do these 'zero size
>>> array means dynamic structure continuation' tricks generally.
>>>
>>> I first mis-parsed the code for a second when seeing cpumask[].
>>> cpumask[0] stands out like a sore thumb. And we dont read comments
>>> anyway ;-)
>>>
>>> Jeff, i suspect you found this because you are working on something
>>> rather interesting? :) If yes, would it help your project if we did
>>> the cpumask[0] cleanup and pushed it upstream immediately?
>> I think cpumask[0] would be more clear and consistent with the
>> rest of the kernel.
>>
>> But unfortunately for the twin projects of (a) static analysis and
>> checking with 'sparse', and (b) compiling under another compiler,
>> VLA-in-middle-of-struct is a killer in either case.
>
> even if at the end of the struct?

Putting the VLA at the end of the struct would be a huge help, yes.

For example, struct sched_group and struct sched_domain are OK as-is
(though "[0]" would be preferred).

It is the definition of struct static_sched_group and struct
static_sched_domain that creates the problem, because with the bitmap
following cpumask[] and span[], the VLA is no longer at the end of the
struct.

VLA-in-the-middle raises the complexity required of the compiler quite a
bit. As a result, VLA-in-middle is not implemented in sparse or clang
(LLVM's C front-end and static analyzer).

Jeff





\
 
 \ /
  Last update: 2009-05-12 04:27    [W:0.596 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site