Re: System call numbers

I wouldn't worry about syscalls NR too much wrt kernel stability.
RHEL4 (CentOS 4) requires we push SSI syscalls to 390 by the way.  It
is a small and simple change.

Roger

On Jan 7, 2008 11:44 AM, John Hughes <[email protected]> wrote:
> Starting around kernel 2.6.13 we start having problems with our SSI
> syscall numbers - we conflict with ones Linus has allocated for other stuff:
>
> E.g. on i386 we use:
>
>     /* BEGIN CLUSTER SYSTEM CALLS */
>     #define __NR_ssisys             290
>     #define __NR_rfork              291
>     #define __NR_rexecve            292
>     #define __NR_migrate            293
>
>     #define NR_syscalls 294
>
> But 2.6.13 has:
>
>     [...]
>     #define __NR_ioprio_get 290
>     #define __NR_inotify_init 291
>     #define __NR_inotify_add_watch 292
>     #define __NR_inotify_rm_watch 293
>
>     #define NR_syscalls 294
>
> Since you're getting ready to make a 2.0, how about we bite the bullet
> now and change our syscall numbers so they're future-proofed up 'till
> say 2.6.24?
>
> We could ensure backwards compatability for older kernels by making
> libcluster first try the new syscall number, and if that fails "not
> implemented" try the old one.
>
> Thoughts?
>
>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace