2.6 kernel syscall changes

[Martin Hunt <hunt@redhat.com>]

The question came up in the tapset discussion, "how much do the system
calls change?"  Here is a very quick answer.

Syscall between 2.6.0 and 2.6.15

-------- i386 -----------

ADDED 
sys_set_zone_reclaim (not used. looks to be removed in 2.6.16)
sys_mbind
sys_get_mempolicy
sys_set_mempolicy
sys_mq_open
sys_mq_unlink
sys_mq_timedsend
sys_mq_timedreceive
sys_mq_notify
sys_mq_getsetattr
sys_sys_kexec_load
sys_waitid
sys_add_key
sys_request_key
sys_keyctl
sys_ioprio_set
sys_ioprio_get
sys_inotify_init
sys_inotify_add_watch
sys_inotify_rm_watch

---------- x86_64 ----------
wrap_sys_shmat renamed sys_shmat
sys_sendfile renamed sys_sendfile64
sys_time64 renamed sys_time
plus added all the same ones as i386
-------------------------------------

Now when building a tapset with current versions of gcc, we also have to
deal with compiler bugs that prevent access to a few parameters in these
functions. And we have to keep in mind that there are system calls
unique to certain cpus, plus when a new syscall is added, it often
doesn't get added to all architectures at the same time. 

Now we can define probe aliases for functions that don't exist in the
current kernel.  If someone requests a probe on one of those, stap
correctly generates a compilation error. 

It is only wildcards that cause a problem. If someone requests a probe
set on all syscalls, then they presumably mean all the appropriate
system calls and any attempts to set probes on nonexistent functions
should be quietly ignored.

I think there also needs to be a way to explicitly request that a probe
be set on a function, if it exists, and otherwise a warning is printed
but the script continues.

So how to efficiently deal with compiler bugs that prevent access to
function parameters or internal variables?  Ideally a warning would be
printed but we would still compile something with the bad parameter or
variable set to some default, like 0 or "unknown". Is this possible?

Martin