lkml.org 
[lkml]   [2001]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Assigning syscall numbers for testing
> 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?

Isn't that a non-issue, based on the patch that was sent? So, you change
a few #define statements to point to other unused slots in the syscall
table, and you're good to go.

If I understood correctly, /proc/dynamic_syscalls contains the information
about dynamically registered syscall name->number associations, which are
placed beyond the end of the currently registered set of syscalls. Later
on down the line when we have 500 syscalls (exaggeration of course), the
patch should still work as intended by just telling it that the empty
slots in the syscall table begin at 501. So now your syscall that was
registered as syscall 241 with the dynamic syscall patch in 2.4.17 now
gets number 502 (or anything else for that matter) with the same patch
under 5.4.23. Whee.

Chris


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.128 / U:2.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site