Re: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures

[Tom Tromey <tromey at redhat dot com>]

Mark> It is a little unfortunate that there is no canonical list of
Mark> syscalls and numbers per architecture.

Reflection for the kernel APIs would be useful here.
;-)

Mark> For some of these "sub-syscalls" I think it would be better to treat
Mark> them as if they were really syscalls for those that are real syscalls on
Mark> some other architecture (that is what strace and systemtap do). And I
Mark> would propose minimize the usage of numbers. So only have a factory
Mark> getSyscall(String) and not one based on numbers (since those differ
Mark> between architectures and make it impossible to get any 'sub-syscalls').
Mark> If so then we should also drop the number() from SyscallEventInfo and
Mark> replace it with a syscall() method that just returns the Syscall object.

This sounds fairly reasonable to me.

One use case I came up with is supporting strace's -o option in
ftrace.  Consider 'ftrace -o <x>'... in this case we'd need to be able
to look at a SyscallEventInfo and test "is it <x>?".  Probably this
would mean putting some "model" object representing the <x> syscall
into a hashset.

In the current setup one plausible approach would be to have multiple
Syscall objects with the same number but different names.  Then,
SyscallEventInfo would have an accessor to return the corresponding
Syscall -- which would be the "decoded" one.  Finally, Syscall would
have an equals() method that would compare both the name and the
number.

The only oddity then would be what to do in the case where an unknown
number is passed to syscallByNum.  But ... I wonder if this should
simply throw an exception.

Tom