Calling syscalls from the kernel [LWN.net]

Calling syscalls from the kernel

Posted Jul 10, 2014 22:21 UTC (Thu) by bourbaki (guest, #84259)
Parent article: Anatomy of a system call, part 1

Hello David,

Thanks for this article, it looks like the start of a very promising series. I have question though, that you or other kernel hackers may answer :

> Calling system calls directly from elsewhere in the kernel is generally discouraged and is not often seen.

I have searched about this a bit but couldn't find a specific reason for why it's "generally discouraged". Could someone enlighten me ?

Thanks

to post comments

Calling syscalls from the kernel

Posted Jul 11, 2014 11:33 UTC (Fri) by roblucid (guest, #48964) [Link] (3 responses)

One general principal reason would be, that lower layer software, breaking out and calling higher layer software, turns a "calling tree" into a "network graph", much harder to analyse and reason about it's performance.

More simply, a system call is designed for user space interaction, in general something in kernel, ought to be using an in-kernel service, rather than re-purposing a user space interface.

[ As noone answered this question yet ]

Calling syscalls from the kernel

Posted Jul 14, 2014 9:33 UTC (Mon) by drysdale (guest, #95971) [Link] (2 responses)

That's roughly my understanding too. System calls typically check all their (user-provided) arguments carefully, and also copy any needed chunks of memory from __user * pointers -- all of which is inefficient for internal usage. So it's more common to have an inner function that the rest of the kernel calls, and the syscall wraps.

Calling syscalls from the kernel

Posted Jul 23, 2014 14:32 UTC (Wed) by YogeshC (guest, #49966) [Link] (1 responses)

In that case, why has this particular syscall been used in half a dozen places inside the kernel? Is there any specific (or general) reason(s) for read/write syscalls to be called from within the kernel space on so many occasions?

Calling syscalls from the kernel

Posted Aug 11, 2014 12:45 UTC (Mon) by rwmj (subscriber, #5474) [Link]

No one answered your question so I'll have a go.

The main user of sys_read at the moment is the code for unpacking the initramfs. You could imagine this "should" be done by a userspace process, because it's doing a lot of userspace-type stuff, like uncompressing a cpio file and then creating a tree of directories and files from it. It's nearly the equivalent of running:

  zcat initramfs | cpio -id

However because the initramfs is needed before userspace is up -- because creating the initramfs is creating the initial userspace -- they have to do this userspace-type stuff in the kernel instead.

So it's a layering violation, but for understandable reasons.