From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10032 invoked from network); 14 Dec 2023 22:10:04 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 14 Dec 2023 22:10:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5DCA443E80; Fri, 15 Dec 2023 08:10:02 +1000 (AEST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) by minnie.tuhs.org (Postfix) with ESMTPS id 116F643E7F for ; Fri, 15 Dec 2023 08:09:58 +1000 (AEST) Received: by mail-ua1-x932.google.com with SMTP id a1e0cc1a2514c-7cae73b1641so19348241.1 for ; Thu, 14 Dec 2023 14:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1702591797; x=1703196597; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=apCtcA6DehCdJUn2OUg6wO3Doo+X3YHIJSjyKydyPMg=; b=O0ni+5yB9izQGjvIo6m5ejSxDeJBRbpHpUPmEtNZvgdcD7vdxvv+LIN567/GJV4nOJ JciUpIBKOIottrw7R/keFUF0N1rWYJn3SQ/d68Y4wuu/5SHaZfkUo5RwMJLG+cPCLFu8 CxuUEDivTtSj1zIo0lwpPP1dMDq5Z3lHLf5ig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702591797; x=1703196597; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=apCtcA6DehCdJUn2OUg6wO3Doo+X3YHIJSjyKydyPMg=; b=P94H9MMlh/ewuDkjK4nukJr0Bxa04WRVPTkdyEdHZASCatudeskAirCogzc1ZJ1ryt RqAzgYOwHRHv0GoK8VGP/bYa3EGCX1rZ9Df26KWr8DZG/p7UCCaqbFbaycuxJbrv8A7c xP0S52kvKf3OAM2D5viQqnvTw6T3yGeijpyWzpOJBxpPzckDMxLnSp55fXavVgGYvQSp qY0WVbryGTWn+6MjAfhJOW2/o82HWT5WMOAwAE0sjIv9MBnoQ6Yh5sm8YFmjiu0Cac0I dcn0W2ghUt/CIIvr78S8xp0XGIEXaCO0iiz3qeeOQNelONCUARfhxEHuz2F4pgguGjxR R0qQ== X-Gm-Message-State: AOJu0YxSCXJ1I8cSPZnHa6xwJIX7OQ9J5Fgg6aRHdfAFfSnsofLnPhFo X01p2ulU7/vg+jqX3XA4q19/x+UsAEyJoHV6FASpZLUrTzcwwM0s X-Google-Smtp-Source: AGHT+IE1HrxlABU7viVCyT1fNnq6QoeIUrEBvR0Y0HWoSrKzNH/R+jn60Qpyt+E9EOptBI9RSvIuCs5dzY7vLLJqLoA= X-Received: by 2002:a05:6102:6cf:b0:464:cac8:a03e with SMTP id m15-20020a05610206cf00b00464cac8a03emr8287213vsg.1.1702591796730; Thu, 14 Dec 2023 14:09:56 -0800 (PST) MIME-Version: 1.0 References: <20231214214805.81B2618C08F@mercury.lcs.mit.edu> In-Reply-To: <20231214214805.81B2618C08F@mercury.lcs.mit.edu> From: Clem Cole Date: Thu, 14 Dec 2023 17:09:20 -0500 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000003dffb8060c7f8bbb" Message-ID-Hash: 3ZQBIMCAHUPG55BY6IJS4GHZEY6YGK7K X-Message-ID-Hash: 3ZQBIMCAHUPG55BY6IJS4GHZEY6YGK7K X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: coff@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Terminology query - 'system process'? List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003dffb8060c7f8bbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =E1=90=A7 On Thu, Dec 14, 2023 at 4:48=E2=80=AFPM Noel Chiappa 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 printe= r > spooler daemon, email daemon, etc, etc) there are some other things that > are > daemon-like, but are fundamentally different in major ways (explained lat= er > below). I dubbed them 'system processes', but I'm wondering if ayone know= s > 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 proces= s > 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 bei= ng > 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 te= rm > '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 afte= r > the kernel itself is started, and there is usually not a special mechanis= m > 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 a= s > 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 > --0000000000003dffb8060c7f8bbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know of a standard name.=C2=A0 =C2=A0We use= d to call the kernel processes or kernel=C2=A0threads also.=C2=A0 For insta= nce, in the original Masscomp EFS code, we had a handful of processes that = got forked after the pager using kernel code.=C2=A0 Since the basic UNIX re= ad/write from the user space scheme is synchronous, the premade pool of ker= nel processes was dispatched as needed when we listened for asynchronous re= mote requests for I/O. This is similar to the fact that asynchronous device= s from serial or network interfaces need a pool of memory to stuff things i= nto since you never know ahead of time when it will come.
3D""=E1= =90=A7

On Thu, Dec 14, 2023 at 4:48=E2=80=AFPM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote= :
So Lars Brinkh= off and I were chatting about daemons:

=C2=A0 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 ar= e
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 "sc= heduling (swapping)
process"), but the CACM "The UNIX Time-Sharing System" paper= :

=C2=A0 https://people.eecs.berkeley.edu/~brew= er/cs262/unix.pdf

doesn't even mention it, so no guidance there. Berkeley UNIX also has o= ne,
mentioned in "Design and Implementation of the Berkeley Virtual Memory=
Extensions to the UNIX Operating System":

=C2=A0 http://roguelife.org/~fujita/COOK= IES/HISTORY/3BSD/design.pdf

where it is called the "pageout daemon".("During system init= ialization, 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&#= 39;
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 'nor= mal'
processes use for loading their code; daemons are often started long after<= br> 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 'in= it'
process, not the kernel); daemons interact with the kernel through system calls, just like 'ordinary' processes; the daemon's process run= s 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 li= nked into
the monolithic kernel, and is thus loaded by the bootstrap; the kernel
contains special provision for starting the system process, which start as<= br> the kernel is starting; they don't do system calls, just call kernel ro= utines
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 wit= h
the operation of the kernel; without the system process(es) operating
correctly, the operation of the system will quickly grind to a halt. The lo= ss
of ordinary' daemons is usually not fatal; if the email daemon dies, th= e
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 th= an
'system process'?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel
--0000000000003dffb8060c7f8bbb--