Re: [patch ping] Cache system call number

[Yao Qi <qiyaoltc at cn dot ibm dot com>]

On Tue, Oct 31, 2006 at 11:39:26AM -0500, Andrew Cagney wrote:
> Yao, have the options:
> 
> - make signal # an explict syscall-entry parameter
> - make signal class an explicit syscall-entry parameter

Hi, Andrew,
I am confused by "signal" here.  Do you mean "signal" == "syscall"?

> 
> been explored.  Clients can then cache the entry parameter locally if 
> they so wish.
> 
> I'm not that comfortable with having the task try to cache the most 
> recent signal: for the code to be robust it will need to also invalidate 
> that value after syscall exit; all clients will be turning around and 
> requesting the value any way as their first op, should it just be provided?
First, let us leave alone syscall info cache and value invalidation
after exit syscall.  Clients are notified by means of SyscallObserver
when the task enter and exit a syscall, to fetch the syscall
information.  If clients fetch syscall information at the moment that
no physical syscall happens in the current task, only a meaningless
 or invalid syscall object or a NegativeSyscallNumberExecption could 
be got.
Syscall.syscallByNum() could be accessed anytime, regardless the
actual syscall happens or not.  That is to say, invalid syscall object
could be got, even if we do not cache the syscall infor.

There might be some other risks, which we do not realize, if we cache
syscall number, and it is fine to me to cache the syscall number on
client side to fix bug#3010(testSyscallInterrupt fails on ppc64).
 
-- 
Yao Qi