Re: About system call handling in Frysk

[Wu Zhou <woodzltc at cn dot ibm dot com>]

Had talked about the goals we might have and the problems I observed,
I'd like to talk about a potential solution I am thinking of now.

(It is only a very initial idea, feel free to point out anything
incorrect.)

First, for each architecture, we can manually maintain a file to 
contain a table for each system calls: the name and its number. 
We can name these files syscallnum-i386.list, syscallnum-ppc64.list
and syscall-x86_64.list. For the very first version of them, we
can get its contents from the latest kernel's asm-xxx/unistd.h
file.  Similar to what is in /usr/include/asm-xxx/unistd.h, these
files contain all the existing system calls in different
architectures. Also included in these files are these old 
deprecated ones, which is not implemented in current kernel.  
A reason not to use the user space one is that I found it is 
sometimes not that up-to-date as its kernel version.  As new 
system call is added, we can add it into these files manually. 
Now that Linux's system call interface is quite stable, this 
workload is very small I believe.

Then, based on these files, we can generate file SyscallNum.java
for different architectures. This can be similar to the current
way.  But it can bring a little more uptodate information.

(BTW, I notice the currrent SyscallNum.shjava will skip these system
call which contain underscore, such as set_thread_area, _llseek.)

Based on these files, we can also partially auto-generate array
Syscall[] syscallList for Syscall.java.  For this file, I want to
suggest a few other changes too:

First, I want to add a flag to indicate whether the sytem call is
multiplexer or not.  If it is, the print process will be different:
it will try to print out the final dispatched system call.  

Next I want to extend member argList to indicate more specifically
about the argument types.  Currently, it supports 'a', 'b', 'p', 
's', 'S' and 'i'.  I am thinking that we can use more letters to
distinguish between different kind of flags, modes, and so on....

We have at least 62 letters to do that (a-zA-Z0-9).  So it can
support a lot of things I believe.  But I am not very sure if it
can represent all these argument types appearing in these system
calls.

Having these different argument types there, maybe we can create
a class to represent that.  What I can figure out now is three data
members: name, length and data; and one method: printer.

In this way, I believe we can work out a more beautiful system call
printer.  Any thought on this?

Regards
- Wu Zhou


On Tue, 21 Mar 2006, Wu Zhou wrote:

> Hi, Anrew and All
> 
> I had some more thinking about the system call handling in Frysk.
> 
> I guess that we need to set our goals first.  IMHO, the following two
> goals might be disirable.  
> 
> (Maybe there are some others, but they are on the top of my mind now. 
> If there are any errors or missing, feel free to correct me. :-)
> 
> 1. to print system calls as intuitively and descriptively as possible
> 
> Saying this, I am trying to mean that we should print the system call
> in such a way that seeing the output, user can get a good understanding
> about what the system call is trying to do, whether it succeed, if 
> failed what is the reason, and so on....
> 
> 2. to support different architectures, including at least i386, ppc64
> and x86_64, easy to extend to include other architectures.
> 
> 
> And to achive these goals, we might need to overcome some problems
> in the current Linux system.  Here are some of my observation:
> 
> - Different architecture support a different set of system calls. 
> i386 has about 292 system calls in 2.6.15, ppc64 has 277, and
> x86_64 has 255.
> 
> - The system calls interface in Linux is quite stable, but there
> are a few changes occasionally.  some old system calls are 
> deprecated, becoming "SYS_NI_SYSCALL"; a few new system call are
> added as new requirement appears.  Is frysk supposed to support
> these old system call in old binary?  And is it also supposed to 
> support these new ones just coming into the new kernel?  I believe
> it will be a good feature if we can support the old deprecated
> system calls and also the latest added ones.
> 
> - Same system call in different architectures might have different
> number, but they should have the same format information, i.e. 
> argument number, argument types and return type. 
> 
> (Is the latter assumption make sense?  I didn't notice any negative 
> proof.  I would be very surprised if someone can prove me wrong. :-)
> 
> - Some architecture are using multiplexer for some kinds of system
> call.  For example, x86 and ppc64 are using ipc for ipc related 
> system calls (shmget, shmdt, shmat.....), and using socketcall for
> socket related system calls (socket, connect, bind, listen...);
> Other architectures don't. For example, x86_64 don't work in that
> way, it has different call number for different ipc and socket
> related system call.
> 
> - We can get the information about a sytem call from the kernel.
> But these information is very raw.  We might need to translate
> them into more human-readable format.
> 
> 
> OK.  These are my current observation.  Any thought on that?
> 
> I will post another mail later to discuss a potential solution
> I am thinking of.
> 
> Thanks.
>