Calling syscalls from the kernel [LWN.net]

Calling syscalls from the kernel

Posted Jul 14, 2014 9:33 UTC (Mon) by drysdale (guest, #95971)
In reply to: Calling syscalls from the kernel by roblucid
Parent article: Anatomy of a system call, part 1

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.

to post comments

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.