Hi! > Add a document describing the process of adding a new system call, > including the need for a flags argument for future compatibility, and > covering 32-bit/64-bit concerns (albeit in an x86-centric way). > > Signed-off-by: David Drysdale <drysdale@xxxxxxxxxx> > Reviewed-by: Michael Kerrisk <mtk.manpages@xxxxxxxxx> > Reviewed-by: Eric B Munson <emunson@xxxxxxxxxx> > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > --- > Documentation/adding-syscalls.txt | 531 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 531 insertions(+) > create mode 100644 Documentation/adding-syscalls.txt We usually align documentation to less than 80 columns, afaict. > +call. To make sure that userspace programs can safely use flags between kernel > +versions, check whether the flags value holds any unknown flags, and reject the > +sycall (with EINVAL) if it does: syscall? > +New system call proposals, like any change to the kernel's API, should always > +be cc'ed to linux-api@xxxxxxxxxxxxxxx . at and of sentence? > +System Calls Returning Elsewhere > +-------------------------------- > + > +For most system calls, once the system call is complete the user program > +continues exactly where it left off -- at the next instruction, with the same > +stack and registers as before the system call, and with the same virtual > +memory space. Umm. Normally we place return value in register. And I'm not sure.. do syscalls preserve registers that are normally caller-clobbered in the ABI? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
