From: Stephen Warren <swarren@wwwdotorg.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Linus Walleij <linus.walleij@linaro.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pinctrl: Include <linux/bug.h> to prevent compile errors
Date: Fri, 09 Mar 2012 16:09:27 -0700 [thread overview]
Message-ID: <4F5A8DA7.5070900@wwwdotorg.org> (raw)
In-Reply-To: <CAP=VYLpZv-g5ZqONzhk51nth3Wn=zHmcfytdEBH3ZX7CJKjaZw@mail.gmail.com>
On 03/09/2012 02:29 PM, Paul Gortmaker wrote:
> On Fri, Mar 9, 2012 at 3:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 03/09/2012 01:32 PM, Paul Gortmaker wrote:
>>> [[PATCH] pinctrl: Include <linux/bug.h> to prevent compile errors] On 09/03/2012 (Fri 13:18) Stephen Warren wrote:
>>>
>>>> Macros in <linux/pinctrl/machine.h> call ARRAY_SIZE(), the definition of
>>>> which eventually calls BUILD_BUG_ON_ZERO(), which is defined in
>>>> <linux/bug.h>. Include that so that every .c file using the pinctrl macros
>>>> doesn't have to do that itself.
>>>
>>> Which C files are failing? The approach was to be adding it only
>>> for headers with static inlines which use it, and add it to C files
>>> that are actually *deploying* the macros.
>>
>> For me, the files that are failing haven't been committed upstream yet;
>> I expect them to be very soon after the 3.4 merge window completes.
>>
>> However, I expect you'll see this issue with arch/arm/mach-u300/core.c,
>> since it uses the same macros defined in pinctrl/machine.h that cause
>> the problem for me, unless one of the include files there picks up bug.h
>> already.
>>
>> As a general statement though, once pinctrl becomes more widely adopted,
>> I expect to see many files start to use macros from pinctrl/machine.h,
>> and hence implicitly use ARRAY_SIZE(), and hence even more implicitly
>> depend on linux/bug.h. I don't think it's at all reasonable to force the
>> author of every one of those files to track down 3 or 4 levels of header
>> file dependencies to find that they need linux/bug.h even though they
>> make no direct use of its features, when it's known that almost any user
>> of pinctrl/machine.h is going to hit this issue.
>
> There was a similar discussion before, where there was concern over
> "every one of those files" but in the end the number is a fraction of
> a percent. There is no harm in the author knowing they are making
> _use_ of BUG stuff -- in fact if you happened to be trying to write some
> fault tolerant code, you might really be glad to know, so you could take
> steps to avoid it....
The primary purpose for pinctrl/machine.h is files that define a certain
data structure that will almost invariably be initialized using the
macros in that header. Size those macros use ARRAY_SIZE, every one of
those .c files will require bug.h.
There are 1 or 2 files in drivers/pinctrl that include pinctrl/machine.h
solely for the data structure definitions or function prototypes, and
won't use those macros, but those are the exception rather than the rule
for this one header at least.
next prev parent reply other threads:[~2012-03-09 23:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 20:18 [PATCH] pinctrl: Include <linux/bug.h> to prevent compile errors Stephen Warren
2012-03-09 20:32 ` Paul Gortmaker
2012-03-09 20:43 ` Stephen Warren
2012-03-09 21:29 ` Paul Gortmaker
2012-03-09 23:09 ` Stephen Warren [this message]
2012-03-12 19:44 ` Linus Walleij
2012-03-12 20:55 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5A8DA7.5070900@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox