Programming

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?

Code:

$ 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.

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.