Thread: [SSI-devel] System call numbers
Brought to you by:
brucewalker,
rogertsang
From: John H. <john@Calva.COM> - 2008-01-07 16:45:09
|
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? |
From: Roger T. <rog...@gm...> - 2008-01-08 03:25:46
|
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 <jo...@ca...> 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? > > > |
From: Roger T. <rog...@gm...> - 2008-01-08 03:39:35
|
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 <rog...@gm...> 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 <jo...@ca...> 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? > > > > > > > |
From: John H. <john@Calva.COM> - 2008-01-08 09:20:53
|
Roger Tsang wrote: > It is very easy to test SSI syscall NR changes for bugs and is one of > the first things we test (hint). > What I'm worried about is upgrades - say I have a nice system with am openssi 2.6.11 kernel, and I upgrade the kernel to 2.6.13 (say). All of a sudden everything stops working. Drat. I install a new libcluster, everything works again. For some reason I have to downgrade the kernel. Bummer, it's all gone wrong again. |
From: Roger T. <rog...@gm...> - 2008-01-08 23:07:47
|
Alright but it will be a feature request, not a bug. On Jan 8, 2008 4:20 AM, John Hughes <jo...@ca...> wrote: > Roger Tsang wrote: > > It is very easy to test SSI syscall NR changes for bugs and is one of > > the first things we test (hint). > > > What I'm worried about is upgrades - say I have a nice system with am > openssi 2.6.11 kernel, and I upgrade the kernel to 2.6.13 (say). > > All of a sudden everything stops working. > > Drat. > > I install a new libcluster, everything works again. > > For some reason I have to downgrade the kernel. > > Bummer, it's all gone wrong again. > > |
From: Stan <sta...@ra...> - 2008-01-09 15:45:51
|
Excellent discussion! We should declare a _flag_ day and from that day forward, SSI system calls are in a known range above 2.6.24 syscalls. Requires adding nop/Not-implemented syscall padding for 2.6.10/11/13...24. The above implies new distro releases ASAP. > -----Original Message----- > From: ssi...@li... > [mailto:ssi...@li...] On > Behalf Of John Hughes > Sent: Tuesday, January 08, 2008 1:21 AM > To: Roger Tsang > Cc: ssic-linux-devel > Subject: Re: [SSI-devel] System call numbers > > Roger Tsang wrote: > > It is very easy to test SSI syscall NR changes for bugs and > is one of > > the first things we test (hint). > > > What I'm worried about is upgrades - say I have a nice system with am > openssi 2.6.11 kernel, and I upgrade the kernel to 2.6.13 (say). > > All of a sudden everything stops working. > > Drat. > > I install a new libcluster, everything works again. > > For some reason I have to downgrade the kernel. > > Bummer, it's all gone wrong again. > > > -------------------------------------------------------------- > ----------- > 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.n et/marketplace > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |