[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1406241549430.29176@chino.kir.corp.google.com>
Date: Tue, 24 Jun 2014 15:51:13 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Guenter Roeck <linux@...ck-us.net>
cc: Chen Gang <gang.chen.5i5j@...il.com>,
Liqin Chen <liqin.linux@...il.com>,
Lennox Wu <lennox.wu@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] rch/score/include/uapi/asm/ptrace.h: Add prefix
'SCORE_' for related macros
On Tue, 24 Jun 2014, Guenter Roeck wrote:
> > diff --git a/arch/score/include/uapi/asm/ptrace.h
> > b/arch/score/include/uapi/asm/ptrace.h
> > index f59771a..56e2de0 100644
> > --- a/arch/score/include/uapi/asm/ptrace.h
> > +++ b/arch/score/include/uapi/asm/ptrace.h
> > @@ -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
> >
> 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:
>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists