Re: rethinking syscall tapset

[Hien Nguyen <hien at us dot ibm dot com>]

Martin Hunt wrote:

> My current thoughts:
>
> 1. Don't use different directories for different versions like the old
> tapset did. Unmaintainable. Almost everything goes in the main
> directory. We can split it into two files, if we want. syscalls1.stp,
> syscalls2.stp. Keep the syscalls alphabetical in the file(s).
>  
Sounds good to me.

> 2. If at all possible, stick to standard kernel versions. No check for
> 2.6.15-1.1824_FC4, etc. 
>
> 3. For arch-specific calls, like stat64() put those in
> i686/syscalls.stp, for example
>
> 4. For new syscalls that get put in for different archs in different
> releases, it may get messy, but they are rare.  Keep in the main
> directory, not in arch-specific subdirs.
>
> 5. The real problem will be if we still run into compiler-related
> problems where some variables are unavailable.
>  
Should the translator be more forgiving (just generate warning) and go on?
I saw in some instances, the syscall argument names have changed from 
one version to another version. It is rare, but we still need to deal 
with it.

> I'll try to work out the documentation format.  
Should the documentation be included in the syscalls.stp? and we use 
some tools to generate the docs (similar to javadoc).

> Then maybe we can split
> the syscalls and each take half?  
>  
Yes, I will be glad to work on this.

Thanks, Hien.