Lines Matching full:new
4 Adding a New System Call
7 This document describes what's involved in adding a new system call to the
15 The first thing to consider when adding a new system call is whether one of
22 object, it may make more sense to create a new filesystem or device. This
23 also makes it easier to encapsulate the new functionality in a kernel module
26 - If the new functionality involves operations where the kernel notifies
27 userspace that something has happened, then returning a new file
35 - If you're just exposing runtime system information, a new node in sysfs
44 this option is best for when the new function is closely analogous to
45 existing :manpage:`fcntl(2)` functionality, or the new functionality is very simple
57 A new system call forms part of the API of the kernel, and has to be supported
109 If your new system call allows userspace to refer to a kernel object, it
111 new type of userspace object handle when the kernel already has mechanisms and
114 If your new :manpage:`xyzzy(2)` system call does return a new file descriptor,
116 ``O_CLOEXEC`` on the new FD. This makes it possible for userspace to close
124 If your system call returns a new file descriptor, you should also consider
130 If your new :manpage:`xyzzy(2)` system call involves a filename argument::
150 If your new :manpage:`xyzzy(2)` system call involves a parameter describing an
154 If your new :manpage:`xyzzy(2)` system call involves privileged functionality,
160 the power of root. In particular, avoid adding new uses of the already
163 If your new :manpage:`xyzzy(2)` system call manipulates a process other than
179 To make new system calls easy to review, it's best to divide up the patchset
185 - Wiring up of the new system call for one particular architecture, usually
187 - A demonstration of the use of the new system call in userspace via a
189 - A draft man-page for the new system call, either as plain text in the
192 New system call proposals, like any change to the kernel's API, should always
199 The main entry point for your new :manpage:`xyzzy(2)` system call will be called
204 this macro allows metadata about the new system call to be made available for
207 The new entry point also needs a corresponding function prototype, in
215 new system call to the generic list by adding an entry to the list in
222 note that if multiple new system calls are added in the same merge window,
223 your new syscall number may get adjusted to resolve conflicts.
226 system call, returning ``-ENOSYS``. Add your new system call here too::
230 Your new kernel functionality, and the system call that controls it, should
232 ``init/Kconfig``) for it. As usual for new ``CONFIG`` options:
234 - Include a description of the new functionality and system call controlled
237 - Make any new source files implementing the function dependent on the CONFIG
239 - Double check that the kernel still builds with the new CONFIG option turned
244 - ``CONFIG`` option for the new function, normally in ``init/Kconfig``
254 To wire up your new system call for x86 platforms, you need to update the
255 master syscall tables. Assuming your new system call isn't special in some
369 the new system call. There's a choice here: the layout of the arguments
449 socket multiplexor (``socketcall``) operations. If your new system call is
453 new system call, it's worth doing a kernel-wide grep for the existing system
460 A new system call should obviously be tested; it is also useful to provide
463 program in a new directory under ``tools/testing/selftests/``.
465 For a new system call, there will obviously be no libc wrapper function and so
467 involves a new userspace-visible structure, the corresponding header will need
474 For more extensive and thorough testing of new functionality, you should also
485 All new system calls should come with a complete man page, ideally using groff
502 new syscall, or needs to be shared between a syscall and its compatibility
547 - LWN article from Michael Kerrisk on avoiding new uses of CAP_SYS_ADMIN:
549 - Recommendation from Andrew Morton that all related information for a new
552 - Recommendation from Michael Kerrisk that a new system call should come with
556 - Suggestion from Greg Kroah-Hartman that it's good for new system calls to
558 - Discussion from Michael Kerrisk of new system call vs. :manpage:`prctl(2)` extension: