From: Eugene Syromiatnikov <esyr@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Alexandre Torgue <alexandre.torgue@st.com>,
Michael Williams <michael.williams@arm.com>,
linux-kernel@vger.kernel.org,
Chunyan Zhang <zhang.chunyan@linaro.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
"Dmitry V. Levin" <ldv@altlinux.org>,
Pratik Patel <pratikp@codeaurora.org>,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] coresight: do not use the BIT() macro in the UAPI header
Date: Tue, 24 Mar 2020 13:13:06 +0100 [thread overview]
Message-ID: <20200324121306.GA5735@asgard.redhat.com> (raw)
In-Reply-To: <20200324101938.GA2220478@kroah.com>
On Tue, Mar 24, 2020 at 11:19:38AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 24, 2020 at 10:53:04AM +0100, Eugene Syromiatnikov wrote:
> > On Tue, Mar 24, 2020 at 07:28:53AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Mar 24, 2020 at 05:22:13AM +0100, Eugene Syromiatnikov wrote:
> > > > The BIT() macro definition is not available for the UAPI headers
> > > > (moreover, it can be defined differently in the user space); replace
> > > > its usage with the _BITUL() macro that is defined in <linux/const.h>.
> > >
> > > Why is somehow _BITUL() ok to use here instead?
> >
> > It is provided in an UAPI header (include/uapi/linux/const.h)
> > and is appropriately prefixed with an underscore to avoid conflicts.
>
> Because no one uses _ in their own macros? :)
Well, it is a reserved prefix (ANSI C99, 4.1.2 "Standard headers": "All
other identifiers that begin with an underscore and either an upper-case
letter or another underscore are reserved"), so valid C files shouldn't
use them.
> Anyway, this is fine, but if it's really the way forward, I think a lot
> of files will end up being changed...
There are 5 cases for using BIT() in UAPI headers so far (rtc.h[1],
serio.h[2], psci.h[3], pkt_sched.h[4], coresight-stm.h), two of them were
conversions from the open-coded variant; the usage of _BITUL in pkt_sched.h
made me think that it is the better approach since people tend to use
BIT-like macro anyway, so, by increasing a number of cases it may raise
awareness of the UAPI specifics.
[1] https://lore.kernel.org/lkml/20200324041209.GA30727@asgard.redhat.com/
[2] https://lore.kernel.org/lkml/20200324041341.GA32335@asgard.redhat.com/
[3] https://lore.kernel.org/lkml/20200324041526.GA1978@asgard.redhat.com/
[4] https://lore.kernel.org/lkml/20200324041920.GA7068@asgard.redhat.com/
>
> thanks,
>
> greg k-h
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Eugene Syromiatnikov <esyr@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
Pratik Patel <pratikp@codeaurora.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Michael Williams <michael.williams@arm.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Chunyan Zhang <zhang.chunyan@linaro.org>,
"Dmitry V. Levin" <ldv@altlinux.org>
Subject: Re: [PATCH] coresight: do not use the BIT() macro in the UAPI header
Date: Tue, 24 Mar 2020 13:13:06 +0100 [thread overview]
Message-ID: <20200324121306.GA5735@asgard.redhat.com> (raw)
In-Reply-To: <20200324101938.GA2220478@kroah.com>
On Tue, Mar 24, 2020 at 11:19:38AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 24, 2020 at 10:53:04AM +0100, Eugene Syromiatnikov wrote:
> > On Tue, Mar 24, 2020 at 07:28:53AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Mar 24, 2020 at 05:22:13AM +0100, Eugene Syromiatnikov wrote:
> > > > The BIT() macro definition is not available for the UAPI headers
> > > > (moreover, it can be defined differently in the user space); replace
> > > > its usage with the _BITUL() macro that is defined in <linux/const.h>.
> > >
> > > Why is somehow _BITUL() ok to use here instead?
> >
> > It is provided in an UAPI header (include/uapi/linux/const.h)
> > and is appropriately prefixed with an underscore to avoid conflicts.
>
> Because no one uses _ in their own macros? :)
Well, it is a reserved prefix (ANSI C99, 4.1.2 "Standard headers": "All
other identifiers that begin with an underscore and either an upper-case
letter or another underscore are reserved"), so valid C files shouldn't
use them.
> Anyway, this is fine, but if it's really the way forward, I think a lot
> of files will end up being changed...
There are 5 cases for using BIT() in UAPI headers so far (rtc.h[1],
serio.h[2], psci.h[3], pkt_sched.h[4], coresight-stm.h), two of them were
conversions from the open-coded variant; the usage of _BITUL in pkt_sched.h
made me think that it is the better approach since people tend to use
BIT-like macro anyway, so, by increasing a number of cases it may raise
awareness of the UAPI specifics.
[1] https://lore.kernel.org/lkml/20200324041209.GA30727@asgard.redhat.com/
[2] https://lore.kernel.org/lkml/20200324041341.GA32335@asgard.redhat.com/
[3] https://lore.kernel.org/lkml/20200324041526.GA1978@asgard.redhat.com/
[4] https://lore.kernel.org/lkml/20200324041920.GA7068@asgard.redhat.com/
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2020-03-24 12:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 4:22 [PATCH] coresight: do not use the BIT() macro in the UAPI header Eugene Syromiatnikov
2020-03-24 4:22 ` Eugene Syromiatnikov
2020-03-24 6:28 ` Greg Kroah-Hartman
2020-03-24 6:28 ` Greg Kroah-Hartman
2020-03-24 9:53 ` Eugene Syromiatnikov
2020-03-24 9:53 ` Eugene Syromiatnikov
2020-03-24 10:19 ` Greg Kroah-Hartman
2020-03-24 10:19 ` Greg Kroah-Hartman
2020-03-24 12:13 ` Eugene Syromiatnikov [this message]
2020-03-24 12:13 ` Eugene Syromiatnikov
2020-03-24 15:31 ` Mathieu Poirier
2020-03-24 15:31 ` Mathieu Poirier
2020-03-26 14:10 ` Greg Kroah-Hartman
2020-03-26 14:10 ` Greg Kroah-Hartman
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=20200324121306.GA5735@asgard.redhat.com \
--to=esyr@redhat.com \
--cc=alexandre.torgue@st.com \
--cc=gregkh@linuxfoundation.org \
--cc=ldv@altlinux.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mathieu.poirier@linaro.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=michael.williams@arm.com \
--cc=pratikp@codeaurora.org \
--cc=zhang.chunyan@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.