* Apurva Mehta <apurva@gmx.net> [08-08-2003 21:53]:
> Hi,
>
> I have a few questions about kernel processes and when system calls
> are made.
>
> When you open a normal data file from within a program and start
> reading from and writing to it, does the backend of the library being
> used always use open, close, read, write? If so, then for each one of
> these calls, does the system switch to kernel mode?
Dont bother with those questions. I think the answers to all of them
is 'yes'.
> Doing a `ps aux` on linux, I get the following kernel processes:
>
> [ksoftirqd/0]
> [events/0]
> [kblockd/0]
> [pdflush]
> [pdflush]
> [kswapd0]
> [aio/0]
> [aio_fput/0]
> [kseriod]
> [kjournald]
> [khubd]
> [kjournald]
> [reiserfs/0]
>
> Is the entire kernel functionality implemented in these processes only?
>
> If so, in which process is scheduling and interrupt handling done? Which
> process handles the switch between processes? Which process services
> system calls? Which process handles the switch between kernel space
> and user space?
>
> If not, where is the other kernel functionality implemented? How is it
> accessed? How is it managed (in terms of scheduling, resource
> allocation, etc)?
>
> I can guess the answers to some of the questions, but I cannot think
> of satisfactory answers to all so that they fit together. Perhaps I
> have not thought hard enough. Perhaps I am thinking down the wrong
> path. If there is documentation, please point me to it.
I have been doing some thinking (and reading) and I think I have an
idea of what happens. I still don't know whether all kernel features
are implemented as specific running processes. However, here is
my outlook on the situation.
_All_ system calls are triggered by software interrupts. Which one
depends on the architecture and the convention used. Now, when a
system call is made, the address of the system_call section of
entry.S is the interrupt vector. This way the kernel
jumps to that address, saves all registers, checks whether it is a
valid call, and then executes it.
Now as far as scheduling is concerned, the timer generates an interrupt
periodically and sets the interrupt vector to the address of the
schedule function. So the scheduler decides which process is to be
executed next and then switches to it. Then an interrupt comes again
and the whole process starts all over. In case a process terminates in
the middle of a time slice, it calls the do_exit function which
somehow calls schedule and the next process is scheduled. This is a
huge guess on my part. Please correct me if I am wrong.
As far as resolving the addresses of the system_call section of
entry.S and the schedule() function goes, I guess the kernel maintains
a pagetable mapping the virtual address to the actual physical
addresses. Just as it does for normal processes.
Also, there is no particular 'process' that is responsible for
switching between processes or switching between modes. When a switch
is made, an assembly routine is run which stores the registers, stack
pointer and other info of the current process into the process table
entry. This assembly routine is probably part of every process and
called just before the process gives up control. Then the stage is
setup for the next process/thread to run.
If I am correct in my guesses, then certain kernel parts are not
implemented as processes at all as they are purely triggered by
interrupts and act accordingly. They just need to exist in memory. But
where they stay is a question I would still like an answer for.
This post is a reflection of my ideas of how the kernel operates
internally. They have been formed based on information from varied
sources (book snippets, source code etc..) and may be completely
wrong. Feedback on the accuracy of my ideas will be greatly
appreciated
Thanks for your time.
- Apurva
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
