On 10/30/2014 06:35 AM, Russell King - ARM Linux wrote: > On Thu, Oct 30, 2014 at 07:30:28AM -0400, Steven Rostedt wrote: >> On Thu, 30 Oct 2014 11:14:41 +0000 >> Russell King - ARM Linux <[email protected]> wrote: >> >> >>> We have always had syscall number range of 0x900000 or so. The tracing >>> design does not expect that. Therefore, the tracing design did not take >>> account of ARM when it was created. Therefore, it's up to the tracing >>> people to decide how to properly fit their ill-designed subsystem into >>> one of the popular and well-established kernel architectures - or at >>> least suggest a way to work around this issue. >>> >> >> >> Fine, lets define a MAX_SYSCALL_NR that is by default NR_syscalls, but >> an architecture can override it. >> >> In trace_syscalls.c, where the checks are done, have this: >> >> #ifndef MAX_SYSCALL_NR >> # define MAX_SYSCALL_NR NR_syscalls >> #endif >> >> change all the checks to test against MAX_SYSCALL_NR instead of >> NR_syscalls. >> >> Then in arch/arm/include/asm/syscall.h have: >> >> #define MAX_SYSCALL_NR 0xa00000 >> >> or whatever would be the highest syscall number for ARM. > > Or do we just ignore the high "special" ARM syscalls and treat them (from > the tracing point of view) as non-syscalls, avoiding the allocation of > something around 1.2MB for the syscall bitmap. I really don't know, I > don't use any of this tracing stuff, so it isn't something I care about. > > Maybe those who do use the facility should have an input here?
I checked strace and it knows about ARM's high syscalls. I wouldn't want to go from casually using strace to digging deeper with ftrace only to get the impression that syscalls are disappearing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
