2.6 kernel syscall changes

2.6 kernel syscall changes

[Martin Hunt]

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

Re: 2.6 kernel syscall changes

[Frank Ch. Eigler]

hunt wrote:

> 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 [20]
> ---------- x86_64 ----------
> RENAMED [3]
> ADDED [same 20]

Thanks.  These numbers give a sense of proportion when discussing the
variability of system calls.  Since 2.6.0 was released in December
2003, two years ago, this averages to less than *one change per
month*, all added or renamed.  This amount of churn does not seem that
serious.


> [...]  Now we can define probe aliases for functions that don't
> exist in the current kernel.

It's a matter of timing the error checks.  At the present, the RHS of
alias definitions is only checked during an alias expansion.  This
could be changed to have the translator check even unused aliases.

I will clarify the HACKING guidelines to spell out that tapset files
should come with a testsuite script that provides sufficient coverage,
for example, by expanding every alias.  Then buggy tapset parts would
be found by the developer rather than the user.

> If someone requests a probe on one of those, stap correctly
> generates a compilation error.  It is only wildcards that cause a
> problem. [...]

Sure, if "an error message caused by direct reference to a
kernel.syscall.buggy_alias" is not "a problem".


> 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.

Can someone imagine a use to "optional" probes, other than the
solitary scenario we've been discussing (trace entry/exit of
"syscalls.*", blocked by buggy alias definitions in syscalls.stp)?


> 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". [...]

In principle, this does not seem ideal to me.  If a user script refers
to some variable for its operation, then we would be doing a
disservice giving it NULL data and pretending everything was OK.  (A
warning message does not solve the problem.  It's either irrelevant to
the user and will thus annoy her, or it's relevant but then letting
the script run will produce erroneous results.)

But the parameter access problem is real.  It would be nice to have
some solution that would be useful even with correct debuginfo.

How about this: the translator could perform an early-stage
optimization during pass 2, which removes some classes of
subexpressions that have no side-effects.  This would include
assignments to variables that are never read.  Probe aliases that copy
a slew of $target variables into local script variables would quietly
tolerate the unresolvability of just those variables that are not used
by the end-user scripts.

Or this: add a syntax like "$?var" to designate var as an optional
value - the nonexistence of which the script is prepared to quietly
accept.

- FChE

Re: 2.6 kernel syscall changes

[Martin Hunt]

On Mon, 2006-01-09 at 13:03 -0500, Frank Ch. Eigler wrote:

> But the parameter access problem is real.  It would be nice to have
> some solution that would be useful even with correct debuginfo.
> 
> How about this: the translator could perform an early-stage
> optimization during pass 2, which removes some classes of
> subexpressions that have no side-effects.  This would include
> assignments to variables that are never read.  Probe aliases that copy
> a slew of $target variables into local script variables would quietly
> tolerate the unresolvability of just those variables that are not used
> by the end-user scripts.

If you could do that, it sounds like a nearly ideal solution.

You fix that, I'll try to fix the syscall tapset by putting it back in
one file and adding a bunch of conditionals on arch and kernel and we'll
see what things look like then. OK?

Martin