Re: [alsa-devel] [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding "linux/" sub-directory
Chen Gang gang.chen@asianux.com wrote:
For "include/uapi/*", excluding "linux/" sub-directory, let all files' macro prefix match the standard format, and give related stand comments for their macro suffix.
The related standard format is:
"_SUBDIRNAME_SUBDIRNAME[_SUBDIRNAME]_FILENAME" (1st _SUBDIRNAME is _UAPI), and use '_' instead of '.' and '-'.
I strongly recommend _against_ this without very careful consideration. Userspace sometimes depends on the name in the guard macro:-/
David
On 11/05/2013 06:03 AM, David Howells wrote:
Chen Gang gang.chen@asianux.com wrote:
For "include/uapi/*", excluding "linux/" sub-directory, let all files' macro prefix match the standard format, and give related stand comments for their macro suffix.
The related standard format is:
"_SUBDIRNAME_SUBDIRNAME[_SUBDIRNAME]_FILENAME" (1st _SUBDIRNAME is _UAPI), and use '_' instead of '.' and '-'.
I strongly recommend _against_ this without very careful consideration.
All first-send interface related patches are not for applying, they are only for discussing.
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).
If we really want to check "a file id", normally we will check some macros which already defined in this header file (or in some scripts, check file path) instead of checking "its file id"
Using the standard format can be sure of file id is always unique in the future, and it also can let our interface (Linux's address) more cleaner and beautiful.
Hmm.. do you mean as an interface, if really have unusual(incorrect) using ways, we have to bear and compatible with them -- although the interface never says "it will not be changed in the future".
Thanks.
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?
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.
David
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.
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.
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.
participants (2)
-
Chen Gang -
David Howells