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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28300 invoked from network); 15 Dec 2023 14:21:37 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2023 14:21:37 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id ED8B143D5F; Sat, 16 Dec 2023 00:21:34 +1000 (AEST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by minnie.tuhs.org (Postfix) with ESMTPS id 216C843D5E for ; Sat, 16 Dec 2023 00:21:30 +1000 (AEST) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2c9f099cf3aso9587141fa.1 for ; Fri, 15 Dec 2023 06:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702650088; x=1703254888; darn=tuhs.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/BrwIXQQd8rZ/D7bgejlLDHll16JPT2bRc9nRY4EeqA=; b=CYuNPJeeZTSgYKOF74DYnwk9cYdjE8ffMDK1qx2MtCBqUYHXc4T4gzNV38IIvfsYNr 8dyUZ6qeliJ7jJt0JDrXlrKtC2p01HeTAQP5fbj6YkHCgwKBNLTu9WBJlSBusS3FMKlz 646HCZK91oFk7e3ppS6N9dwF+IEnYwFj+um1Ir2XK5gX0nQ+Mg3gT/fnTxhKWkWmZV6H I8UleBqiEfIhcLCNrA0zjSzFHYxDQTtvbWv0R2JZjyUP26cE3t99EI653H7Tz3o82IHC yFVDnuGHk+rlgBswd8rrRX4CUomviMGU7G3yVb4X9GJUU+f7R1Xpd0e1duduT1/Ilm8j SSvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702650088; x=1703254888; h=content-transfer-encoding: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=/BrwIXQQd8rZ/D7bgejlLDHll16JPT2bRc9nRY4EeqA=; b=n8P0cOWPOZ8MDVGlye0lQ/mSRDmSWFRt0H2jE1fYZOUJKApcIg9A6eNTjIMl+brgBa /El2M71QGaDqw/k1AdcjnmcW/5JSBAttkVZllw9TOA4EgggijhSG/l+DNOxHuHRwPv/o J9oNtJ01b7Bekc1/Y1Bu2DDYnV7OPywArR6z48bJLOx7l4Dq7vMcqayQ/26ro/XvDzKH vSCLYe6dW2y0MssvhCJ5gNUkKsV8gJxLE/NduxcNpsrD8Te55SeECSN7eP1MM2wQqXnj uCblfabOhMfvD830z8pwHKSv75cnyA7ApIZuvlJKj7ZVkk1FQ3oKSyFM7gYAnz0DzlQh PYlw== X-Gm-Message-State: AOJu0YzeBFbK7HQkYya3+h0kwijccPnek7GIUgT4fd+Cv4sxa7KtYMds i57YHyPmb5DBgQN1ai31/0YvLAX/U8UMEyfTLi0= X-Google-Smtp-Source: AGHT+IGf+Q0qPYmhmUFWlTMwSu+jDCCjFhHDE0vxl1Rf17kHCWZmgPBxdGNyJ/cNlvTT/wLrlsNlKomWKg2341FVmb0= X-Received: by 2002:a05:651c:1145:b0:2cc:1ee4:a930 with SMTP id h5-20020a05651c114500b002cc1ee4a930mr7479224ljo.106.1702650088101; Fri, 15 Dec 2023 06:21:28 -0800 (PST) MIME-Version: 1.0 References: <20231214214805.81B2618C08F@mercury.lcs.mit.edu> In-Reply-To: From: Dan Cross Date: Fri, 15 Dec 2023 09:20:51 -0500 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: J24QJ4BESOSJ3A3KXIMNQXJBQRQEG6SH X-Message-ID-Hash: J24QJ4BESOSJ3A3KXIMNQXJBQRQEG6SH X-MailFrom: crossd@gmail.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: Noel Chiappa , 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: On Thu, Dec 14, 2023 at 5:17=E2=80=AFPM Clem Cole wrote: > I don't know of a standard name. We used to call the kernel processes o= r 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 proc= esses that got forked after the pager using kernel code. Since the basic U= NIX read/write from the user space scheme is synchronous, the premade pool = of kernel processes was dispatched as needed when we listened for asynchron= ous 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 th= ings into since you never know ahead of time when it will come. > =E1=90=A7 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=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 print= er >> spooler daemon, email daemon, etc, etc) there are some other things that= are >> daemon-like, but are fundamentally different in major ways (explained la= ter >> below). I dubbed them 'system processes', but I'm wondering if ayone kno= ws 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 "sche= duling (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 on= e, >> 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 proce= ss 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 be= ing >> 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 t= erm >> '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 aft= er >> the kernel itself is started, and there is usually not a special mechani= sm in >> the kernel to start daemons (on early UNIXes, /etc/rc is run by the 'ini= t' >> process, not the kernel); daemons interact with the kernel through syste= m >> calls, just like 'ordinary' processes; the daemon's process runs in 'use= r' >> 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 rou= tines >> 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