Lines Matching refs:call
4 This document describes what's involved in adding a new system call to the
12 The first thing to consider when adding a new system call is whether one of
37 fcntl(2) is a multiplexing system call that hides a lot of complexity, so
43 fcntl(2), this system call is a complicated multiplexor so is best reserved
51 A new system call forms part of the API of the kernel, and has to be supported
63 system call. To make sure that userspace programs can safely use flags
65 flags, and reject the system call (with EINVAL) if it does:
102 If your new system call allows userspace to refer to a kernel object, it
107 If your new xyzzy(2) system call does return a new file descriptor, then the
116 If your system call returns a new file descriptor, you should also consider
122 If your new xyzzy(2) system call involves a filename argument:
141 If your new xyzzy(2) system call involves a parameter describing an offset
145 If your new xyzzy(2) system call involves privileged functionality, it needs
146 to be governed by the appropriate Linux capability bit (checked with a call to
154 If your new xyzzy(2) system call manipulates a process other than the calling
155 process, it should be restricted (using a call to ptrace_may_access()) so that
160 system call parameters that are explicitly 64-bit fall on odd-numbered
173 - The core implementation of the system call, together with prototypes,
175 - Wiring up of the new system call for one particular architecture, usually
177 - A demonstration of the use of the new system call in userspace via a
179 - A draft man-page for the new system call, either as plain text in the
182 New system call proposals, like any change to the kernel's API, should always
189 The main entry point for your new xyzzy(2) system call will be called
192 of arguments to the system call, and the macro takes the system call name
194 this macro allows metadata about the new system call to be made available for
205 new system call to the generic list by adding an entry to the list in
211 Also update the __NR_syscalls count to reflect the additional system call, and
216 call, returning -ENOSYS. Add your new system call here too:
220 Your new kernel functionality, and the system call that controls it, should
224 - Include a description of the new functionality and system call controlled
244 To wire up your new system call for x86 platforms, you need to update the
245 master syscall tables. Assuming your new system call isn't special in some
263 the userspace program is itself 32-bit; even if the system call's parameters
271 64-bit values. In particular, this is needed whenever a system call argument
280 system call's arguments has a type that is explicitly 64-bit even on a 32-bit
285 (Note that a system call argument that's a pointer to an explicit 64-bit type
287 type loff_t __user * do not trigger the need for a compat_ system call.)
289 The compatibility version of the system call is called compat_sys_xyzzy(), and
295 them call a common inner implementation function.)
303 If the system call involves a structure that is laid out differently on 32-bit
329 The generic system call list also needs adjusting to allow for the compat
347 To wire up the x86 architecture of a system call with a compatibility version,
357 the new system call. There's a choice here: the layout of the arguments
370 call for the x32 ABI (and consequently the entry in
381 For most system calls, once the system call is complete the user program
383 stack the same and most of the registers the same as before the system call,
390 To allow for this, the kernel implementation of the system call may need to
392 control of where and how execution continues after the system call.
395 that save/restore additional registers and invoke the real system call entry
411 If the system call needs a compatibility layer (as in the previous section)
412 then the stub32_ version needs to call on to the compat_sys_ version of the
413 system call rather than the native 64-bit version. Also, if the x32 ABI
431 occasional exception that may need updating for your particular system call.
434 functions that classify some special types of system call -- specifically
436 multiplexor (socketcall) operations. If your new system call is analogous to
439 More generally, if there is an existing system call that is analogous to your
440 new system call, it's worth doing a kernel-wide grep for the existing system
441 call to check there are no other special cases.
447 A new system call should obviously be tested; it is also useful to provide
449 call. A good way to combine these aims is to include a simple self-test
452 For a new system call, there will obviously be no libc wrapper function and so
453 the test will need to invoke it using syscall(); also, if the system call
485 call: https://lwn.net/Articles/588444/
486 - LWN article from Jake Edge describing constraints on 64-bit system call
488 - Pair of LWN articles from David Drysdale that describe the system call
502 system call should come in the same email thread:
504 - Recommendation from Michael Kerrisk that a new system call should come with
510 - Discussion from Michael Kerrisk of new system call vs. prctl(2) extension: