[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a3Fc8EQLP=vsRbajeF1xp8mX5xbgoCaa3dOn=XozYiWdQ@mail.gmail.com>
Date: Mon, 27 Sep 2021 17:43:19 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Coly Li <colyli@...e.de>
Cc: Kent Overstreet <kmo@...erainc.com>, Arnd Bergmann <arnd@...db.de>,
Jens Axboe <axboe@...nel.dk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC] bcache: hide variable-sized types from uapi headers
On Mon, Sep 27, 2021 at 5:22 PM Coly Li <colyli@...e.de> wrote:
>
> On 9/27/21 8:43 PM, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@...db.de>
> >
> > The headers_check helper complains about a GNU extension in
> > one of the exported headers:
> >
> > linux/bcache.h:354:2: warning: field '' with variable sized type 'union jset::(anonymous at ./usr/include/linux/bcache.h:354:2)' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> > BKEY_PADDED(uuid_bucket);
> > ^
> > linux/bcache.h:134:2: note: expanded from macro 'BKEY_PADDED'
> > union { struct bkey key; __u64 key ## _pad[BKEY_PAD]; }
> > ^
> >
> > We could either try to shut up the warning or remove those parts from
> > the user-visible section of this header. This does the second,
> > under the assumption that they are not actually used.
>
> Hi Arnd,
>
> Yes, the variable part is necessary for bcache-tools to understand the
> on-disk format. If other program wants to understand the bcache on-disk
> format, IMHO such variable part might be necessary too.
Ok, got it.
> BKEY_PADDED() is a special usage of the variable size array. In this
> case it indicates uuid_bucket is 8 x u64, and 6 x u64 space for ptr[].
> And the bcache code make sure no more than 6 pointers are used for
> uuid_bucket.
>
> I know BKEY_PADDED() works, but I don't know how to simply remove the
> -Wgnu-variable-sized-type-not-at-end warning.
>
> Maybe Kent may offer some hint ?
Maybe instead of checking for __KERNEL__, we could check for
__STRICT_ANSI__ being unset. This would hide the definition
from user space applications that don't have this extension, and from
the header check but still allow it in all applications built with gcc
or clang that don't request the strict standard compliance.
Another option is to exclude this header from the header-test
in usr/include/Makefile.
Arnd
Powered by blists - more mailing lists