Just how can I locate the executions of Linux kernel system calls?

I am attempting to recognize just how a function, claim mkdir, functions by considering the bit source. This is an effort to recognize the bit internals and also browse in between numerous features. I recognize mkdir is specified in sys/stat.h. I located the model:

/* Create a new directory named PATH, with permission bits MODE.  */
extern int mkdir (__const char *__path, __mode_t __mode)
     __THROW __nonnull ((1));

Currently I require to see in which C documents this function is applied. From the source directory site, I attempted

ack "int mkdir"

which presented

103:static int mkdir(struct inode *dir, struct dentry *dentry, int mode)

4:int mkdir_p(char *path, mode_t mode)

259:int mkdir_p(char *path, mode_t mode);

Yet none matches the definition in sys/stat.h.


  1. Which documents has the mkdir execution?
  2. With a function definition like the above, just how can I figure out which documents has the execution? Exists any kind of pattern which the bit adheres to in specifying and also applying approaches?

KEEP IN MIND: I am making use of bit 2.6.36-rc1.

2019-05-04 08:29:59
Source Share
Answers: 7

An excellent area to read the Linux kernel source is the Linux cross-reference (LXR) ¹. Searches return keyed in suits (features models, variable affirmations, etc) along with free message search engine result, so it is handier than a plain grep (and also much faster also).

LXR does not expand preprocessor interpretations. System calls have their name mangled by the preprocessor everywhere. Nonetheless, most (all?) system calls are specified with among the SYSCALL_DEFINEx family members of macros. Given that mkdir takes 2 debates, a look for SYSCALL_DEFINE2(mkdir brings about the declaration of the :

SYSCALL_DEFINE2(mkdir, const char __user *, pathname, int, mode)
    return sys_mkdirat(AT_FDCWD, pathname, mode);

ok, sys_mkdirat suggests it is the mkdirat syscall, so clicking it just leads you to the declaration in include/linux/syscalls.h, yet the definition is simply above.

The major work of mkdirat is to call vfs_mkdir (VFS is the common filesystem layer). Cliking on that particular reveals 2 search engine result : the declaration in include/linux/fs.h, and also the definition a couple of lines over. The major work of vfs_mkdir is to call the filesystem - details execution : dir->i_op->mkdir. To locate just how this is applied, you require to resort to the execution of the specific filesystem, and also there is no tough - and also - rapid regulation-- it can also be a component outside the bit tree.

¹ LXR is an indexing program. There are numerous internet sites that give a user interface to LXR, with a little various collections of well-known variations and also a little various internet user interfaces. They often tend ahead and also go, so if the one you are made use of to isn't readily available, do an internet look for "linux cross - reference" to locate an additional.

2019-05-17 22:31:10

Here are a pair actually wonderful post defining numerous strategies for searching down reduced - degree bit source code.

2019-05-16 22:00:27

Note : the.h documents does not specify the function. It's proclaimed in that.h documents and also specified (applied) in other places. This permits the compiler to include details concerning the function's trademark (model) to permit type monitoring of debates and also match the return kinds to any kind of calling contexts in your code.

In general.h (header) documents in C are made use of to proclaim features and also specify macros.

mkdir specifically is a system call. There might be a GNU libc wrapper around that system call (likely is, actually). Truth bit execution of mkdir can be located by looking the bit resources and also the system calls certain.

Keep in mind that there will certainly additionally be an execution of some type of directory site production code for each and every filesystem. The VFS (digital filesystem) layer gives an usual API which the system call layer can call right into. Every filesystem has to register features for the VFS layer to call right into. This permits various filesystems to implement their very own semiotics for just how directory sites are structured (as an example if they are saved making use of some type of hashing system to make looking for details access extra reliable). I state this due to the fact that you're most likely to journey over these filesystem details directory site production operates if you're looking the Linux kernel source tree.

2019-05-08 18:52:14

None of the executions you located matches the model in sys/stat. h Maybe looking for an include declaration with this header file would certainly be extra effective?

2019-05-08 15:32:34

This possibly does not address your inquiry straight, yet I've located strace to be actually trendy when attempting to recognize the hidden system calls, at work, that are created also the most basic shell commands. as an example

strace -o trace.txt mkdir mynewdir

The system asks for the command mkdir mynewdir will certainly be unloaded to trace.txt for your watching satisfaction.

2019-05-08 15:17:38

System calls are generally covered in the SYSCALL_DEFINEx() macro, which is why a straightforward grep does not locate them :

fs/namei.c:SYSCALL_DEFINE2(mkdir, const char __user *, pathname, int, mode)

The last function name after the macro is increased winds up being sys_mkdir. The SYSCALL_DEFINEx() macro includes boilerplate points like mapping code that each syscall definition requires to have.

2019-05-08 12:19:46

System calls aren't taken care of like normal function telephone calls. It takes unique code to make the change from customer room to bit room, primarily a little inline setting up code infused right into your program at the call website. The bit side code that "catches" the system call is additionally reduced - degree things you possibly do not require to recognize deeply, at the very least in the beginning.

In include/linux/syscalls.h under your bit source directory site, you find this :

asmlinkage long sys_mkdir(const char __user *pathname, int mode);

After that in /usr/include/asm*/unistd.h, you find this :

#define __NR_mkdir                              83
__SYSCALL(__NR_mkdir, sys_mkdir)

This code is claiming mkdir(2) is system call # 83. That is to claim, system calls are called by number, not by address similar to a regular function call within your very own program or to a function in a collection connected to your program. The inline setting up adhesive code I stated over usages this to make the change from customer to bit room, taking your parameters in addition to it.

An additional little proof that points are a little unusual below is that there isn't constantly a rigorous parameter checklist for system calls : open(2), as an example, can take either 2 or 3 parameters. That suggests open(2) is overloaded, an attribute of C+npls, not C, yet the syscall user interface is C - suitable. (This is not the very same point as C's varargs feature, which permits a solitary function to take a variable variety of debates.)

To address your first inquiry, there is no file where mkdir() exists. Linux sustains several documents systems and also every one has its very own execution of the "mkdir" procedure. The abstraction layer that allows the bit hide all that behind a solitary system call is called the VFS. So, you possibly intend to start excavating in fs/namei.c, with vfs_mkdir(). The real executions of the reduced - degree documents system changing code are in other places. As an example, the ext4 execution is called ext4_mkdir(), specified in fs/ext4/namei.c.

When it comes to your 2nd inquiry, of course there are patterns to all this, yet not a solitary regulation. What you in fact require is a rather wide understanding of just how the bit operates in order to identify where you need to seek any kind of certain system call. Not all system calls entail the VFS, so their bit - side call chains do not all start in fs/namei.c. mmap(2), as an example, begins in mm/mmap.c, due to the fact that it's component of the memory monitoring (" mm") subsystem of the bit.

I advise you get a duplicate of "Understanding the Linux Kernel" by Bovet and also Cesati.

2019-05-08 10:41:07