Messages in this thread | | | Date | Tue, 24 Mar 2020 13:13:06 +0100 | From | Eugene Syromiatnikov <> | Subject | Re: [PATCH] coresight: do not use the BIT() macro in the UAPI header |
| |
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 >
| |