Skip to contentSkip to conversation

rch/score/include/uapi/asm/ptrace.h: Add prefix 'SCORE_' for related macros

PATCH In review Chen Gang 4 participants 8 messages Jun 24, 2014 – Jun 25, 2014

lore
Share & tools
lore

Chen Gang

author
#0 lore raw

PATCH v2 1/1 rch/score/include/uapi/asm/ptrace.h: Add prefix 'SCORE_' for related macros

'COUNTER' and other same kind macros are too common to use, and easy to get conflict with other modules. So add prefix for them.

And it is UAPI, so only change it within linux kernel.

The related warning (allmodconfig with score):

CC [M] drivers/md/raid1.o
In file included from drivers/md/raid1.c:42:0:
drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX) ^
In file included from ./arch/score/include/asm/ptrace.h:4:0,

                   from include/linux/sched.h:31,
                   from include/linux/blkdev.h:4,
                   from drivers/md/raid1.c:36:

./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition
#define COUNTER 38

---
 arch/score/include/uapi/asm/ptrace.h | 33 +++++++++++++++++++++++----------
 1 file changed, 23 insertions(+), 10 deletions(-)
arch/score/include/uapi/asm/ptrace.h +23 -10
index f59771a..56e2de0 100644
@@ -4,16 +4,29 @@
 #define PTRACE_GETREGS		12
 #define PTRACE_SETREGS		13
 
-#define PC		32
-#define CONDITION	33
-#define ECR		34
-#define EMA		35
-#define CEH		36
-#define CEL		37
-#define COUNTER		38
-#define LDCR		39
-#define STCR		40
-#define PSR		41
+#if !defined(__KERNEL__) || !defined(__linux__)
+#define PC			32
+#define CONDITION		33
+#define ECR			34
+#define EMA			35
+#define CEH			36
+#define CEL			37
+#define COUNTER			38
+#define LDCR			39
+#define STCR			40
+#define PSR			41
+#else
+#define SCORE_PC		32
+#define SCORE_CONDITION		33
+#define SCORE_ECR		34
+#define SCORE_EMA		35
+#define SCORE_CEH		36
+#define SCORE_CEL		37
+#define SCORE_COUNTER		38
+#define SCORE_LDCR		39
+#define SCORE_STCR		40
+#define SCORE_PSR		41
+#endif
 
 #define SINGLESTEP16_INSN	0x7006
 #define SINGLESTEP32_INSN	0x840C8000
Signature · 1 line
1.9.2.459.g68773ac
#1 lore raw
Quoted 60 lines · Chen Gang

'COUNTER' and other same kind macros are too common to use, and easy to get conflict with other modules. So add prefix for them.

And it is UAPI, so only change it within linux kernel.

The related warning (allmodconfig with score):

CC [M] drivers/md/raid1.o
In file included from drivers/md/raid1.c:42:0:

   drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
    #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
    ^
   In file included from ./arch/score/include/asm/ptrace.h:4:0,
                    from include/linux/sched.h:31,
                    from include/linux/blkdev.h:4,
                    from drivers/md/raid1.c:36:
   ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition
    #define COUNTER  38
---
  arch/score/include/uapi/asm/ptrace.h | 33 +++++++++++++++++++++++----------
  1 file changed, 23 insertions(+), 10 deletions(-)
arch/score/include/uapi/asm/ptrace.h +16 -10
index f59771a..56e2de0 100644
@@ -4,16 +4,29 @@
  #define PTRACE_GETREGS		12
  #define PTRACE_SETREGS		13
 
-#define PC		32
-#define CONDITION	33
-#define ECR		34
-#define EMA		35
-#define CEH		36
-#define CEL		37
-#define COUNTER		38
-#define LDCR		39
-#define STCR		40
-#define PSR		41
+#if !defined(__KERNEL__) || !defined(__linux__)
+#define PC			32
+#define CONDITION		33
+#define ECR			34
+#define EMA			35
+#define CEH			36
+#define CEL			37
+#define COUNTER			38
+#define LDCR			39
+#define STCR			40
+#define PSR			41
+#else
+#define SCORE_PC		32
+#define SCORE_CONDITION		33
+#define SCORE_ECR		34
+#define SCORE_EMA		35

arch/score/include/uapi/asm/ptrace.h line 32

Quoted 10 lines
arch/score/include/uapi/asm/ptrace.h +7 -0
+#define SCORE_CEH		36
+#define SCORE_CEL		37
+#define SCORE_COUNTER		38
+#define SCORE_LDCR		39
+#define SCORE_STCR		40
+#define SCORE_PSR		41
+#endif
 
  #define SINGLESTEP16_INSN	0x7006
  #define SINGLESTEP32_INSN	0x840C8000

That looks weird ... not sure if that is a good solution either.

Are those defines actually used anywhere ? They don't seem to be used in the kernel.

Side note - an 'a' got missing in your headline. And I'd suggest to abbreviate it to something like
score/uapi: ptrace.h:

Thanks,
Guenter

#2 lore raw
Quoted 48 lines · Guenter Roeck
Quoted 36 lines
arch/score/include/uapi/asm/ptrace.h +16 -10
index f59771a..56e2de0 100644
@@ -4,16 +4,29 @@
  #define PTRACE_GETREGS		12
  #define PTRACE_SETREGS		13
 
-#define PC		32
-#define CONDITION	33
-#define ECR		34
-#define EMA		35
-#define CEH		36
-#define CEL		37
-#define COUNTER		38
-#define LDCR		39
-#define STCR		40
-#define PSR		41
+#if !defined(__KERNEL__) || !defined(__linux__)
+#define PC			32
+#define CONDITION		33
+#define ECR			34
+#define EMA			35
+#define CEH			36
+#define CEL			37
+#define COUNTER			38
+#define LDCR			39
+#define STCR			40
+#define PSR			41
+#else
+#define SCORE_PC		32
+#define SCORE_CONDITION		33
+#define SCORE_ECR		34
+#define SCORE_EMA		35

arch/score/include/uapi/asm/ptrace.h line 32

Quoted 10 lines
arch/score/include/uapi/asm/ptrace.h +7 -0
+#define SCORE_CEH		36
+#define SCORE_CEL		37
+#define SCORE_COUNTER		38
+#define SCORE_LDCR		39
+#define SCORE_STCR		40
+#define SCORE_PSR		41
+#endif
 
  #define SINGLESTEP16_INSN	0x7006
  #define SINGLESTEP32_INSN	0x840C8000

That looks weird ... not sure if that is a good solution either.

Quoted 7 lines

Are those defines actually used anywhere ? They don't seem to be used in the kernel.

Side note - an 'a' got missing in your headline. And I'd suggest to abbreviate it to something like
score/uapi: ptrace.h:

Besides checking whether they are used in the kernel or not, I presume we would need to be fairly confident there are actual userspace usecases for these that require the change. It begs the question of why these constants are too generic to be in the kernel but are acceptable in the set of userspace applications in the world.

#3 lore raw
Quoted 58 lines · David Rientjes
Quoted 48 lines · Guenter Roeck
Quoted 36 lines
arch/score/include/uapi/asm/ptrace.h +16 -10
index f59771a..56e2de0 100644
@@ -4,16 +4,29 @@
   #define PTRACE_GETREGS		12
   #define PTRACE_SETREGS		13
 
-#define PC		32
-#define CONDITION	33
-#define ECR		34
-#define EMA		35
-#define CEH		36
-#define CEL		37
-#define COUNTER		38
-#define LDCR		39
-#define STCR		40
-#define PSR		41
+#if !defined(__KERNEL__) || !defined(__linux__)
+#define PC			32
+#define CONDITION		33
+#define ECR			34
+#define EMA			35
+#define CEH			36
+#define CEL			37
+#define COUNTER			38
+#define LDCR			39
+#define STCR			40
+#define PSR			41
+#else
+#define SCORE_PC		32
+#define SCORE_CONDITION		33
+#define SCORE_ECR		34
+#define SCORE_EMA		35

arch/score/include/uapi/asm/ptrace.h line 32

Quoted 10 lines
arch/score/include/uapi/asm/ptrace.h +7 -0
+#define SCORE_CEH		36
+#define SCORE_CEL		37
+#define SCORE_COUNTER		38
+#define SCORE_LDCR		39
+#define SCORE_STCR		40
+#define SCORE_PSR		41
+#endif
 
   #define SINGLESTEP16_INSN	0x7006
   #define SINGLESTEP32_INSN	0x840C8000

That looks weird ... not sure if that is a good solution either.

Quoted 7 lines

Are those defines actually used anywhere ? They don't seem to be used in the kernel.

Side note - an 'a' got missing in your headline. And I'd suggest to abbreviate it to something like
score/uapi: ptrace.h:

Quoted 6 lines

Besides checking whether they are used in the kernel or not, I presume we would need to be fairly confident there are actual userspace usecases for these that require the change. It begs the question of why these constants are too generic to be in the kernel but are acceptable in the set of userspace applications in the world.

That is another question. But for the time being it might be sufficient to surround the defines with #if !defined(__KERNEL__) without introducing new (and unused) kernel defines.

Guenter

#4 lore raw
Quoted 4 lines · Guenter Roeck

That is another question. But for the time being it might be sufficient to surround the defines with #if !defined(__KERNEL__) without introducing new (and unused) kernel defines.

On the other hand, if no userspace is referencing these, then you could just rename them and move them out of the uapi header to include/asm/ptrace.h and be done with it.

author
#5 lore raw
Quoted 11 lines · David Rientjes
Quoted 4 lines · Guenter Roeck

That is another question. But for the time being it might be sufficient to surround the defines with #if !defined(__KERNEL__) without introducing new (and unused) kernel defines.

On the other hand, if no userspace is referencing these, then you could just rename them and move them out of the uapi header to include/asm/ptrace.h and be done with it.

OK, thanks. And sorry for the subject lost 'a', firstly. And it is related with UAPI, so it is really important enough to let related maintainer to notice about it.

I guess, only the related maintainer know whether can remove these macros out of "include/uapi/asm/ptrace.h" (although in current upstream kernel source, they are really not used).

It is abnormal in uapi headers for same values with different macros switched by "__KERNEL__", but if we have to remain them still in uapi, we have to use "__KERNEL__ && __linux__" to carm down kernel and user.

Thanks.

Signature · 3 lines
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
#6 lore raw

These marcos are listed in advance.
Indeed, they have not been used, and the functions use them have not be released.
I would like to keep the status even if the configure should not be used. However, if guys think it is dirty, maybe we can remove or comment them first.

Best,
Lennox

2014-06-25 9:25 GMT+08:00 Chen Gang <[email protected]>:

Quoted 33 lines · David Rientjes
Quoted 11 lines · Guenter Roeck
Quoted 5 lines

That is another question. But for the time being it might be sufficient to surround the defines with #if !defined(__KERNEL__) without introducing new (and unused) kernel defines.

On the other hand, if no userspace is referencing these, then you could just rename them and move them out of the uapi header to include/asm/ptrace.h and be done with it.

OK, thanks. And sorry for the subject lost 'a', firstly. And it is related with UAPI, so it is really important enough to let related maintainer to notice about it.

I guess, only the related maintainer know whether can remove these macros out of "include/uapi/asm/ptrace.h" (although in current upstream kernel source, they are really not used).

It is abnormal in uapi headers for same values with different macros switched by "__KERNEL__", but if we have to remain them still in uapi, we have to use "__KERNEL__ && __linux__" to carm down kernel and user.

Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

author
#7 lore raw
Quoted 3 lines · Lennox Wu

These marcos are listed in advance.
Indeed, they have not been used, and the functions use them have not be released.

UAPI is the main interface for contribution to outside, that is our main goal, and has the highest priority.

After new contents are added into UAPI, it is very hard to remove them
again: it is protocol, can only be complement, but can not be changed (or will be a 'cheat').

Quoted 3 lines

I would like to keep the status even if the configure should not be used. However, if guys think it is dirty, maybe we can remove or comment them first.

So, for me, if we find the new contents in UAPI may have negative effect to outside, we need stop it firstly (at least, not let it merged into main line).

If no any additional reply for it within this week, I shall send patch v3 for it (simply remove them).

Thanks.

Signature · 3 lines
Chen Gang

Open share and attitude like air water and life which God blessed