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

On Thu, Dec 14, 2023 at 5:17 PM Clem Cole <clemc@ccc.com> wrote:
> I don't know of a standard name.   We used to call the kernel processes or kernel threads also.

I've heard all combinations of (system|kernel) (thread|task|process),
all of which mean more or less the same thing: something the kernel
can schedule and run that doesn't have a userspace component, reusing
the basic concurrency primitives in the kernel for its own internal
purposes. I'm not sure I've heard "kernel daemon" before, but
intuitively I'd lump it into the same category unless I was told
otherwise (as Noel mentioned, of course Berkeley had the "pageout
daemon" which ran only in the kernel).

> 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.
> ᐧ

I remember reading a paper on the design of NFS (it may have been the
BSD paper) and there was a note about how the NFS server process ran
mostly in the kernel; user code created it, but pretty much all it did
was invoke a system call that implemented the server. That was kind of
neat.

        - Dan C.

> 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

  reply	other threads:[~2023-12-15 14:21 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
2023-12-15 14:20   ` Dan Cross [this message]
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=CAEoi9W7RqjWXu2RGukRqkbKx8hf0ORTepMPCbwxZz2uLB12buw@mail.gmail.com \
    --to=crossd@gmail.com \
    --cc=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).