Re: System call numbers

It is very easy to test SSI syscall NR changes for bugs and is one of
the first things we test (hint).

On Jan 7, 2008 10:25 PM, Roger Tsang <[email protected]> wrote:
> 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