[COFF] Terminology query - 'system process'?

Clem Cole clemc at ccc.com
Fri Dec 15 08:09:20 AEST 2023


I don't know of a standard name.   We used to call the kernel processes or
kernel threads also.  For instance, in the original Masscomp EFS code, we
had a handful of processes that got forked after the pager using kernel
code.  Since the basic UNIX read/write from the user space scheme is
synchronous, the premade pool of kernel processes was dispatched as needed
when we listened for asynchronous remote requests for I/O. This is similar
to the fact that asynchronous devices from serial or network interfaces
need a pool of memory to stuff things into since you never know ahead of
time when it will come.
ᐧ

On Thu, Dec 14, 2023 at 4:48 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> So Lars Brinkhoff and I were chatting about daemons:
>
>   https://gunkies.org/wiki/Talk:Daemon
>
> and I pointed out that in addition to 'standard' daemons (e.g. the printer
> spooler daemon, email daemon, etc, etc) there are some other things that
> are
> daemon-like, but are fundamentally different in major ways (explained later
> below). I dubbed them 'system processes', but I'm wondering if ayone knows
> if
> there is a standard term for them? (Or, failing that, if they have a
> suggestion for a better name?)
>
>
> Early UNIX is one of the first systems to have one (process 0, the
> "scheduling (swapping)
> process"), but the CACM "The UNIX Time-Sharing System" paper:
>
>   https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf
>
> doesn't even mention it, so no guidance there. Berkeley UNIX also has one,
> mentioned in "Design and Implementation of the Berkeley Virtual Memory
> Extensions to the UNIX Operating System":
>
>   http://roguelife.org/~fujita/COOKIES/HISTORY/3BSD/design.pdf
>
> where it is called the "pageout daemon".("During system initialization,
> just
> before the init process is created, the bootstrapping code creates process
> 2
> which is known as the pageout daemon. It is this process that .. writ[es]
> back modified pages. The process leaves its normal dormant state upon being
> waken up due to the memory free list size dropping below an upper
> threshold.") However, I think there are good reasons to dis-favour the term
> 'daemon' for them.
>
>
> For one thing, typical daemons look (to the kernel) just like 'normal'
> processes: their object code is kept in a file, and is loaded into the
> daemon's process when it starts, using the same mechanism that 'normal'
> processes use for loading their code; daemons are often started long after
> the kernel itself is started, and there is usually not a special mechanism
> in
> the kernel to start daemons (on early UNIXes, /etc/rc is run by the 'init'
> process, not the kernel); daemons interact with the kernel through system
> calls, just like 'ordinary' processes; the daemon's process runs in 'user'
> CPU mode (using the same standard memory mapping mechanisms, just like
> blah-blah).
>
> 'System processes' do none of these things: their object code is linked
> into
> the monolithic kernel, and is thus loaded by the bootstrap; the kernel
> contains special provision for starting the system process, which start as
> the kernel is starting; they don't do system calls, just call kernel
> routines
> directly; they run in kernel mode, using the same memory mapping as the
> kernel itself; etc, etc.
>
> Another important point is that system processes are highly intertwined
> with
> the operation of the kernel; without the system process(es) operating
> correctly, the operation of the system will quickly grind to a halt. The
> loss
> of ordinary' daemons is usually not fatal; if the email daemon dies, the
> system will keep running indefinitely. Not so, for the swapping process, or
> the pageout daemon
>
>
> Anyway, is there a standard term for these things? If not, a better name
> than
> 'system process'?
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20231214/e6189e32/attachment.htm>


More information about the COFF mailing list