System call numbers

John Hughes <[email protected]>
Newsgroups gmane.linux.cluster.ssic.devel
Message-ID <[email protected]>
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?



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.