Quote:
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.
