My understanding is that
- a process always runs in user mode and uses user space only, and
- a kernel always runs in kernel mode and uses kernel space only.
But I feel that I might not be correct, after reading the following two books. Could you correct me if I am wrong?
-
In Linux Kernel Architecture by Maurer, the terms "system process"
and "user process" are used without definitions, for example, when
introducing division of virtual address space into kernel space and
user space:Every user process in the system has its own virtual address range
that extends from 0 to TASK_SIZE . The area above (from TASK_SIZE to 2
32 or 2 64 ) is reserved exclusively for the kernel — and may not be
accessed by user processes. TASK_SIZE is an architecture-specific
constant that divides the address space in a given ratio — in IA-32
systems, for instance, the address space is divided at 3 GiB so that
the virtual address space for each process is 3 GiB; 1 GiB is
available to the kernel because the total size of the virtual address
space is 4 GiB. Although actual figures differ according to
architecture, the general concepts do not. I therefore use these
sample values in our further discussions.This division does not depend on how much RAM is available. As a
result of address space virtualization, each user process thinks it
has 3 GiB of memory. The userspaces of the individual system
processes are totally separate from each other. The kernel space at
the top end of the virtual address space is always the same,
regardless of the process currently executing.… The kernel divides the virtual address space into two parts so that it is able to protect the individual
system processes from each other.You can read more examples, by searching either "user process" or
"system process" in the book.Are both user processes and system processes processes, as opposed
to kernel?What are their definitions? Do they differ by their owners (regular
user or root?), by the user who started them, or by something else?Why does the book explicitly write "system process" or "user
process", rather than just "process" to cover both kinds of
"processes", for example, in the above quote? I guess what it says
about "user process" also applies to "system process", and what it
says about "system process" also applies to "user process". -
In Understanding Linux Kernel by Bovet, there are concepts "kernel
control path" and "kernel thread".A kernel control path denotes the sequence of instructions executed by the kernel to
handle a system call, an exception, or an interrupt.… Traditional Unix systems delegate some critical tasks to
intermittently running processes, including flushing disk caches,
swapping out unused pages, servicing network connections, and so on.
Indeed, it is not efficient to perform these tasks in strict linear
fashion; both their functions and the end user processes get better
response if they are scheduled in the background. Because some of the
system processes run only in Kernel Mode, modern operating systems delegate their functions to kernel threads, which are not
encumbered with the unnecessary User Mode con- text. In Linux, kernel
threads differ from regular processes in the following ways:• Kernel threads run only in Kernel Mode, while regular processes run
alterna- tively in Kernel Mode and in User Mode.• Because kernel threads run only in Kernel Mode, they use only linear
addresses greater than PAGE_OFFSET . Regular processes, on the other
hand, use all four gigabytes of linear addresses, in either User Mode
or Kernel Mode.You can read more by searching them at Google Books.
Are "system process" in Maurer's book and in Bovet's book the same concept?
Can "system process" mentioned in the two books run in user space, kernel space, or both?
Is "system process" different from kernel control path and kernel thread?
Best Answer
In the case of Linux, a task (kernel internal idea of a thread; threads can share resources, like memory and open files; some run only inside the kernel) can run in userland, or (it's thread of execution) can transfer into the kernel (and back) to execute a system call. A user thread can be highjacked temporarily to execute an interrupt (but that isn't really that thread running).
That a process is a "system process" or a regular user process is completely irrelevant in Unix, they are handled just the same. In Linux case, some tasks run in-kernel to handle miscellaneous jobs. They are kernel jobs, not "system processes" however.
One big caveat: Text books on complex software products (compilers and operating systems are particularly egregious examples) tend to explain simplistic algorithms (often ones that haven't been used in earnest for half a century), because real world machines and user requirements are much too complex to be handled in some way that can be described in a structured, simple way. Much of a compiler is ad-hoc tweaks (particularly in the area of code optimization, the transformations are mostly the subset of possibilities that show up in practical use). In the case of Linux, most of the code is device drivers (mentioned in passing as device-dependent in operating system texts), and of this code a hefty slice is handling misbehaving devices, which do not comply to their own specifications, or which behave differently between versions of "the same device". Often what is explained in minute detail is just the segment of the job that can be reduced to some nice theory, leaving the messy, irregular part (almost) completely out. For instance, Cris Fraser and David Hanson in their book describing the LCC compiler state that typical compiler texts contain mostly explanations on lexical analysis and parsing, and very little on code generation. Those tasks are some 5% of the code of their (engineered to be simple!) compiler, and had negligible error rate. The complex part of the compiler is just not covered in standard texts.