Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: coff@tuhs.org
Subject: [COFF] Re: Terminology query - 'system process'?
Date: Thu, 14 Dec 2023 17:09:20 -0500	[thread overview]
Message-ID: <CAC20D2MXAh+dcA=rj4hqZhGt4RLnTU==fuoZWTp+Y+eMvK7zGw@mail.gmail.com> (raw)
In-Reply-To: <20231214214805.81B2618C08F@mercury.lcs.mit.edu>

[-- Attachment #1: Type: text/plain, Size: 3929 bytes --]

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@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
>

[-- Attachment #2: Type: text/html, Size: 5141 bytes --]

  parent reply	other threads:[~2023-12-14 22:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 21:48 [COFF] " Noel Chiappa
2023-12-14 22:06 ` [COFF] " Bakul Shah
2023-12-14 22:12   ` Warner Losh
2023-12-14 22:09 ` Clem Cole [this message]
2023-12-15 14:20   ` Dan Cross
2023-12-15 16:25     ` Warner Losh
2023-12-15 17:13     ` Bakul Shah
2023-12-15  6:24 ` Lars Brinkhoff
2023-12-15 18:30   ` Stuff Received
2023-12-14 23:29 Noel Chiappa
2023-12-14 23:54 ` Larry McVoy
2023-12-15  1:15 ` Bakul Shah
2023-12-15 17:51   ` Paul Winalski
2023-12-15 18:08     ` Warner Losh
2023-12-16  2:04     ` Greg 'groggy' Lehey
2023-12-16 19:21       ` Paul Winalski
2023-12-16 19:44         ` Paul Winalski
2023-12-15 13:43 ` Dan Cross
2023-12-19 13:54 ` Derek Fawcus via COFF
2023-12-20 19:31 Noel Chiappa
2023-12-20 20:29 ` Paul Winalski
2023-12-31  3:51 ` steve jenkin
2023-12-20 20:35 Noel Chiappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2MXAh+dcA=rj4hqZhGt4RLnTU==fuoZWTp+Y+eMvK7zGw@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=coff@tuhs.org \
    --cc=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).