can a linux kernel module call libc functions?

can a linux kernel module call libc functions, such as printf(), strcpy(), etc...?

No, absolutely not. There are internal, kernel-specific functions for some of those. If you're asking this question, you must absolutely read the O'Reilley published book on writing Linux device drivers.

How can you do printf() when you don't even have terminals or files? The kernel is what makes libc possible.

I mean in a DIY kernel module that is not significant to the kernel.
How printk print messages when it have no terminals?
Can the kernel module call syscalls?

printk goes to a buffer inside the kernel. Things inside userspace read from it (try dmesg). The log system also reads from it. Nothing in this scheme requires the kernel to have access to system calls or libc.

It's possible to use a hardware serial port(probably not a USB one) in an extremely limited way by setting it as an output for printk messages with options on the kernel commandline. Again, neither libc nor system calls are used.

The kernel really, genuinely doesn't have libc or system calls. The kernel is what makes them possible, if you're not running in user mode you don't have them. We're not joking, kidding, or lying to you.

I know it is the kernel which makes syscalls and libc possible.
But, what makes the kernel can not call syscalls which inside itself?

(If you received mail of this post, it was premature. Disregards)

Linux (AFAIK) does not support a 're-entrant' model. Once you're inside the kernel, you can't thread a new process, or go again into the kernel (you're already there). Allowing a module to do a syscall would make things incredibly complicated and would more than often result in a deadlock or worse -- a infinite recursive loop, filling up the stack.

Some UNIX's (Solaris 2.5+) are re-entrant and theoretically could support a kernel module making a syscall, but again, the problems are similar - extreme care has to be taken to ensure that bad things dont happen.

If you want to have a kernel module do some nifty things, the common practice is to have it communicate with a userland process via a pipe or ioctl. That is, make your module act as a dummy device driver which fills the dummy device with data that it wants to send to the userland process. The userland process is then blocking-read on this device and acts appropriately when the data is available.

There is also the issue of calling symantics. On most devices (ie, CPUs), invoking a system call involves setting registers and triggering an interrupt, which the kernel then handles. If your code is running in the Kernel, this interrupt has to be masked to prevent another system call from interrupting the currently executing one. (Unless you're a re-entrant kernel like Solaris; then your code has to be re-entrant too). In other instances, the system call entry point is through a specific CPU instruction -- one which requires a mode bit to indicate the currently executing process is in "userland" mode. Once the control is handed to the kernel, the kernel sets that bit accordingly, so once again, the CPU wont let a kernel thread invoke a kernel thread.

Thank you otheus.
very enlightening.

Again, thank you all.

Do you? You don't seem to want to accept the implications.

All the fuzzy details of how things work are laid bare inside the kernel, and it must keep track of a lot more stuff than you do. That's why it's done inside the kernel, so you don't have to.

So you want to open a file inside the kernel. Great. Do open("/path/to/file", O_RDWR) call inside the kernel -- whoops, there isn't one.

Which open would you like?

$ grep open System.map-2.6.34-gentoo-r6

ffffffff810077e0 t setup_data_open
ffffffff81010f7d t fake_panic_fops_open
ffffffff81010fc7 t mce_open
ffffffff8101286a t severities_coverage_open
ffffffff81013802 t mtrr_open
ffffffff81017a64 t msr_open
ffffffff81017d92 t cpuid_open
ffffffff8101f661 t microcode_open
ffffffff81026c26 t memtype_seq_open
ffffffff8102dfee t schedstat_open
ffffffff8103a80c t execdomains_proc_open
ffffffff8103f78c T open_softirq
ffffffff81040d82 t iomem_open
ffffffff81040db4 t ioports_open
ffffffff81058022 t pm_qos_power_open
ffffffff8105a110 t prof_cpu_mask_proc_open
ffffffff8105cca8 t timer_list_open
ffffffff8105ffd8 t tstats_open
ffffffff81064123 t proc_dma_open
ffffffff81065859 t modules_open
ffffffff81069cb1 t kallsyms_open
ffffffff8106dda8 t snapshot_open
ffffffff8106efac t acct_file_reopen
...

Assuming you can even find a real_ultimate_kernel_mode_open_which_acts_just_like_userspace_open() call somewhere in that list, how do you use it? When you call open() from a process, the kernel knows what process you're calling it from, so it can alter your process' open file table. You don't have a process. How's it supposed to track it?

Turns out the kernel has its own global file table, which is all well and good, but means your real_ultimate_kernel_mode_open_which_acts_just_like_userspace_open() call won't work -- without a process, many important data structures are missing. You need to alter the global table and avoid needing any userspace one.

So you'd need to find something which alters the kernel's own global file table instead. call it kernel_internal_open(). Okay, good. Now consider whether it's safe to call kernel_internal_open() from your device driver. Might the kernel want you to lock some mutex first? What if something else has already locked it -- is it really okay for your kernel code to sit waiting? Or is the other thing going to sit waiting forever, waiting for you while you're waiting for it? And what kind of waiting should you do? Is a spinlock good enough, or do you have to tell the kernel to pre-empt yourself somehow so other things can happen while you're waiting?

What if kernel_internal_open is already the function that's calling you? Wouldn't all the data structures you want already be busy? It might happen -- that's how device drivers work, big central kernel functions are switchboards for choosing which device driver callbacks to call...

If you have a process, this is an easy fix. The calling process is suspended until the kernel has the right conditions to deal with it, plus the kernel automatically knows all kinds of things about you. But when you don't have a process, suddenly there's all kinds of things you need to worry about.

The concept of "process" is an artificial thing. It pretends very hard to have ideal conditions all the time even when the kernel might be flailing like mad behind the scenes. It's a very tranquil and safe place. The kernel is not. That's why its the kernel.

1 Like

Thank you Corona688

Thanks for your patient and zeal. I will study the kernel earnestly. One years ago, I know nothing about linux. It is UNIX.COM who accompanies my way to linux. Thank you all. Thanks for the great forum.