[RFC,PATCH] arch/arm: compute and export NR_syscalls

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Aug 17, 2011 at 11:22:48AM +0200, Arnd Bergmann wrote:
> On Wednesday 17 August 2011, Mikael Pettersson wrote:
> >  > I proposed this approach based solely on prior threads I've seen. E.g.,
> >  > - https://lkml.org/lkml/2007/6/1/427
> >  >   (don't just #define)
> >  > - https://lkml.org/lkml/2009/8/27/280
> >  >   (todo: x86-32 to move to x86-64)
> >  > 
> >  > If a single line #define is good enough, then it certainly works for me.
> > 
> > Yes, the one-line #define NR_syscalls in unistd.h is a perfectly adequate,
> > if not entirely elegant, solution.  Adding asm-export.c just for this is
> > waaay overkill.
> 
> Right. While the main problem with having the constant in asm/unistd.h
> (needs to be kept in sync when adding new syscalls) is an annoyance,
> the suggested approach is adding more complexity than necessary.
> 
> If you want to have the value automatically computed, I'd suggest
> moving the format of unistd.h over to a method like the one used
> by x86-64 and asm-generic, which is to combine the syscall number
> definitions with the list of syscall pointers that currently reside
> in arch/arm/kernel/calls.S, for the added benefit that it's easier to
> keep the two in sync as well.

You obviously haven't looked at calls.S - the table has multiple
options depending on whether its being used for EABI or OABI.  It's
not purely a 1:1 mapping between syscall number name and function
name.

Adding an additional parameter to the CALL() macro to get around that
for the syscall number name starts making the file unweidly, especially
if we obey the 80 column limit.

Finally, the assembly 'number of syscalls' is different from the real
number of syscalls to ensure that we don't overflow the 8-bit constant
limit for the compare instruction.  Whether that needs to be included
in the C __NR_syscalls or not depends on how its used.

I personally would prefer C code not to rely on the (unprovided)
NR_syscalls due to these kinds of issues.

Finally, if its just for ftrace, well I don't have a high regard for that
code.  It's something I hardly ever use and when I have tried to use it
it has been soo dire in terms of overheads that it's just not worth
bothering with.  When I want timings out of the kernel, I have always
(and continue to do so) implement my own gathering mechanisms rather
than using the ftrace crap.