Re: [patch] Assigning syscall numbers for testing

[Keith Owens <kaos@sgi.com>]

On Sat, 22 Dec 2001 18:25:57 -0500, 
Benjamin LaHaise <bcrl@redhat.com> wrote:
>On Sun, Dec 23, 2001 at 10:18:26AM +1100, Keith Owens wrote:
>> You did not read my mail all the way through, did you?  I said -
>> 
>> If the [user space] code cannot open /proc/dynamic_syscalls or cannot
>> find the desired syscall name, fall back to the assigned syscall number
>> (if any) or fail if there is no assigned syscall number.  By falling
>> back to the assigned syscall number, new versions of the user space
>> code are backwards compatible, on older kernels it will use the dynamic
>> syscall number, on newer kernels it will use the assigned number.
>
>No, that's not the case I'm talking about: what happens when a vendor 
>starts shipping this patch and Linus decides to add a new syscall that 
>uses a syscall number that the old kernel used for dynamic syscalls?

That is why the dynamic syscall range starts well above the currently
allocated range.  If you are looking at my first mail then the patch is
wrong, in my second mail with the correct patch (first patch line is
17.1/kernel/Makefile) the dynamic range starts at 240.