All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: David Howells <dhowells@redhat.com>
Cc: xen-devel@lists.xensource.com, jeremy@goop.org, airlied@linux.ie,
	daniel.vetter@ffwll.ch, alsa-devel@alsa-project.org,
	dri-devel@lists.freedesktop.org, perex@perex.cz,
	thierry.reding@gmail.com, linux-mtd@lists.infradead.org,
	sean.hefty@intel.com, virtualization@lists.linux-foundation.org,
	Linux-Arch <linux-arch@vger.kernel.org>,
	"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
	tbergstrom@nvidia.com, jy0922.shim@samsung.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	roland@purestorage.com, Takashi Iwai <tiwai@suse.de>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	mtk.manpages@gmail.com, fcoe-devel@open-fcoe.org,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	"plagnioj@jcrosoft.com" <plagnioj@jcrosoft.com>,
	Arnd Bergmann <arnd@arndb.de>,
	swarren@wwwdotorg.org, intel-gfx@lists.freedesktop.org,
	inki.dae@samsung.com,
	"linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger>
Subject: Re: [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding "linux/" sub-directory
Date: Thu, 07 Nov 2013 10:53:16 +0800	[thread overview]
Message-ID: <527B009C.4060905@asianux.com> (raw)
In-Reply-To: <5278DEF8.2030101@asianux.com>

On 11/05/2013 08:05 PM, Chen Gang wrote:
> On 11/05/2013 07:11 PM, David Howells wrote:
>> Chen Gang <gang.chen@asianux.com> wrote:
>>
>>>> Userspace sometimes depends on the name in the guard macro:-/
>>>
>>> "the guard macro" is only for prevent itself from being included by
>>> multiple times (an id used by itself -- like a handle), it is not an id
>>> to let other files know about it (it is not a normal using way).
>>
>> Whilst that *should* be true, it isn't actually true.  See:
>>
>> 	grep -r _LINUX_.*_H /usr/include/ | grep -v ^/usr/include/linux/
>>
>> for example.  Also who knows what all those autoconf scripts out there look
>> for?
>>
> 
> Oh... the real world is really not quite perfect. :-/
> 
> 
>> However, thinking about it some more, you're probably safe with respect to
>> userspace as scripts/headers_install.h strips off the _UAPI prefix on the
>> guard macros - just as long as you don't change the rest of the macro name.
>>
> 

I will preparing the patch for it, it will cover "include/uapi/*" and
"arch/*/include/uapi/*", the patch will only add "_UAPI" for the guard
macros which miss it.

Welcome any additional suggestions and completions.

Thanks.

> In honest, I really did not think more about it.
> 
> Only adding _UAPI (not touch others) can completely fix one style issue:
> separate "uapi/*" from other sub-directories in "include/*"
> 
> So for me, we can continue improve this patch: add "_UAPI" for all guard
> macro under "include/uapi/*" (also include "include/uapi/linux").
> 
> 
> Thanks.
> 


-- 
Chen Gang

WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: David Howells <dhowells@redhat.com>
Cc: xen-devel@lists.xensource.com, jeremy@goop.org, airlied@linux.ie,
	daniel.vetter@ffwll.ch, alsa-devel@alsa-project.org,
	dri-devel@lists.freedesktop.org, perex@perex.cz,
	thierry.reding@gmail.com, linux-mtd@lists.infradead.org,
	sean.hefty@intel.com, virtualization@lists.linux-foundation.org,
	Linux-Arch <linux-arch@vger.kernel.org>,
	"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
	tbergstrom@nvidia.com, jy0922.shim@samsung.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	roland@purestorage.com, Takashi Iwai <tiwai@suse.de>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	mtk.manpages@gmail.com, fcoe-devel@open-fcoe.org,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	"plagnioj@jcrosoft.com" <plagnioj@jcrosoft.com>,
	Arnd Bergmann <arnd@arndb.de>,
	swarren@wwwdotorg.org, intel-gfx@lists.freedesktop.org,
	inki.dae@samsung.com,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	linux-tegra@vger.kernel.org, davej@redhat.com,
	Thomas Gleixner <tglx@linutronix.de>,
	robert.w.love@intel.com,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	'Jiri Kosina' <trivial@kernel.org>,
	dedekind1@gmail.com, sw0312.kim@samsung.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	JBottomley@parallels.com,
	"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	dwmw2@infradead.org, David Miller <davem@davemloft.net>,
	shanim@mellanox.com
Subject: Re: [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding "linux/" sub-directory
Date: Thu, 07 Nov 2013 10:53:16 +0800	[thread overview]
Message-ID: <527B009C.4060905@asianux.com> (raw)
In-Reply-To: <5278DEF8.2030101@asianux.com>

On 11/05/2013 08:05 PM, Chen Gang wrote:
> On 11/05/2013 07:11 PM, David Howells wrote:
>> Chen Gang <gang.chen@asianux.com> wrote:
>>
>>>> Userspace sometimes depends on the name in the guard macro:-/
>>>
>>> "the guard macro" is only for prevent itself from being included by
>>> multiple times (an id used by itself -- like a handle), it is not an id
>>> to let other files know about it (it is not a normal using way).
>>
>> Whilst that *should* be true, it isn't actually true.  See:
>>
>> 	grep -r _LINUX_.*_H /usr/include/ | grep -v ^/usr/include/linux/
>>
>> for example.  Also who knows what all those autoconf scripts out there look
>> for?
>>
> 
> Oh... the real world is really not quite perfect. :-/
> 
> 
>> However, thinking about it some more, you're probably safe with respect to
>> userspace as scripts/headers_install.h strips off the _UAPI prefix on the
>> guard macros - just as long as you don't change the rest of the macro name.
>>
> 

I will preparing the patch for it, it will cover "include/uapi/*" and
"arch/*/include/uapi/*", the patch will only add "_UAPI" for the guard
macros which miss it.

Welcome any additional suggestions and completions.

Thanks.

> In honest, I really did not think more about it.
> 
> Only adding _UAPI (not touch others) can completely fix one style issue:
> separate "uapi/*" from other sub-directories in "include/*"
> 
> So for me, we can continue improve this patch: add "_UAPI" for all guard
> macro under "include/uapi/*" (also include "include/uapi/linux").
> 
> 
> Thanks.
> 


-- 
Chen Gang

WARNING: multiple messages have this Message-ID (diff)
From: gang.chen@asianux.com (Chen Gang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding "linux/" sub-directory
Date: Thu, 07 Nov 2013 10:53:16 +0800	[thread overview]
Message-ID: <527B009C.4060905@asianux.com> (raw)
In-Reply-To: <5278DEF8.2030101@asianux.com>

On 11/05/2013 08:05 PM, Chen Gang wrote:
> On 11/05/2013 07:11 PM, David Howells wrote:
>> Chen Gang <gang.chen@asianux.com> wrote:
>>
>>>> Userspace sometimes depends on the name in the guard macro:-/
>>>
>>> "the guard macro" is only for prevent itself from being included by
>>> multiple times (an id used by itself -- like a handle), it is not an id
>>> to let other files know about it (it is not a normal using way).
>>
>> Whilst that *should* be true, it isn't actually true.  See:
>>
>> 	grep -r _LINUX_.*_H /usr/include/ | grep -v ^/usr/include/linux/
>>
>> for example.  Also who knows what all those autoconf scripts out there look
>> for?
>>
> 
> Oh... the real world is really not quite perfect. :-/
> 
> 
>> However, thinking about it some more, you're probably safe with respect to
>> userspace as scripts/headers_install.h strips off the _UAPI prefix on the
>> guard macros - just as long as you don't change the rest of the macro name.
>>
> 

I will preparing the patch for it, it will cover "include/uapi/*" and
"arch/*/include/uapi/*", the patch will only add "_UAPI" for the guard
macros which miss it.

Welcome any additional suggestions and completions.

Thanks.

> In honest, I really did not think more about it.
> 
> Only adding _UAPI (not touch others) can completely fix one style issue:
> separate "uapi/*" from other sub-directories in "include/*"
> 
> So for me, we can continue improve this patch: add "_UAPI" for all guard
> macro under "include/uapi/*" (also include "include/uapi/linux").
> 
> 
> Thanks.
> 


-- 
Chen Gang

  reply	other threads:[~2013-11-07  2:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02  7:39 [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding "linux/" sub-directory Chen Gang
2013-08-02  7:39 ` Chen Gang
2013-08-02  7:39 ` Chen Gang
2013-08-02  7:44 ` Chen Gang
2013-08-02  7:44 ` Chen Gang
2013-08-02  7:44   ` Chen Gang
2013-08-02  7:44   ` Chen Gang
2013-08-02  8:13   ` Eric W. Biederman
2013-08-02  8:13     ` Eric W. Biederman
2013-08-02  8:13     ` Eric W. Biederman
2013-08-02  8:31     ` Chen Gang
2013-08-02  8:31     ` Chen Gang
2013-08-02  8:31       ` Chen Gang
2013-08-02  8:31       ` Chen Gang
2013-11-04 22:03 ` David Howells
2013-11-04 22:03   ` David Howells
2013-11-04 22:03   ` David Howells
2013-11-05  3:34   ` Chen Gang
2013-11-05  3:34   ` Chen Gang
2013-11-05  3:34     ` Chen Gang
2013-11-05  3:34     ` Chen Gang
2013-11-05 11:11     ` David Howells
2013-11-05 11:11       ` David Howells
2013-11-05 11:11       ` David Howells
2013-11-05 12:05       ` Chen Gang
2013-11-05 12:05         ` Chen Gang
2013-11-05 12:05         ` Chen Gang
2013-11-07  2:53         ` Chen Gang [this message]
2013-11-07  2:53           ` Chen Gang
2013-11-07  2:53           ` Chen Gang
2013-11-07  2:53         ` Chen Gang
2013-11-05 11:11     ` David Howells
2013-11-04 22:03 ` David Howells
  -- strict thread matches above, loose matches on Subject: below --
2013-08-02  7:39 Chen Gang

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=527B009C.4060905@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=airlied@linux.ie \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dhowells@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fcoe-devel@open-fcoe.org \
    --cc=inki.dae@samsung.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jeremy@goop.org \
    --cc=jy0922.shim@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-samsung-soc@vger \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=perex@perex.cz \
    --cc=plagnioj@jcrosoft.com \
    --cc=roland@purestorage.com \
    --cc=sean.hefty@intel.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tbergstrom@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xensource.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 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.