Talk:Daemon

Demon, dragon, phantom

I'd like to expand the discussion on this page, or create a separate page, to include the usage of demon on ITS, and also the related dragon. On WAITS, there's a related phantom concept which I don't really know but I intend to find out. Since these are all various form of system background processes, they are similar and so might be best discusses in a single place. Or there could be separate pages for each. Having typed all this, I now figure I should just go ahead and then we can move things around later. Ok, thanks for reading! Larsbrinkhoff (talk) 07:40, 14 August 2023 (CEST)

Yeah, they are all basically the same thing, so cover them all in one page.

The only technical difference worth noting is between 'classic' daemons, such as line printer and email daemons, and what I seem to recall are called 'system processes', which are key parts of the OS itself, and in the case of the Unix 'swapping' process, live entirely in the kernel and never run in 'user' mode. That process doesn't get its code from a file; its code is built into the kernel, and so is loaded at the same time, and by the same mechanism, as the kernel itself.

Those would be worth a separate page, if we can find a 'usual' term for such things. The Unix CACM paper doesn't mention it; a comment in the code calls it the "scheduling (swapping) process". I vaguely recall the term 'system process' being used for such things, but I do not remember where from.

I think the ITS 'CORE JOB' might be in this category (and I seem to recall the code for it is in SYSTEM;); do you know more about it? I have this vague memory that it writes 'dirty' pages out, to maintain a free list. (Multics has a similar concept, IIRC; it would be covered in the Multics Storage System Program Logic Manual. Without looking, I don't recall if it's done as a process, or if Multics just writes dirty pages as part of the page fault code.)

What does the 'SYS SYS' job in ITS do? Is it just an idle process? (The PDP-10 doesn't have a WAIT instruction, the way the PDP-11 does, I am pretty sure.) I think Puff just keeps records of command usage - or am I confused? COMSAT was more of a classic daemon.

I don't recall the term 'demon' ever being used for any of these things. Ever since 'daemon' was adopted under CTSS, that was the term. (Someone who'd heard it used, but never seen it, might have used the incorrect spelling.) Jnc (talk) 15:12, 14 August 2023 (CEST)

I checked; Multics does not have a process whose job it is to write dirty pages. "This starting of writes is performed by the subroutine claim_mod_core in page_fault. This subroutine is invoked at the end of every page fault." (pg. 8-36, pg. 166 of the PDF.) Maybe I am remembering the Berkeley paging code added to 32V? (I'm too lazy to find the paper describing their work.) It makes sense to have a system process do this; having the page fault code do it just makes that code more complicated. (The code in V6 to swap processes in and out is beautifully simple.)

The ITS SYS JOB (code in SYSTEM; SYSJOB) does seem to be a system job - its code is in the kernel - although "DEMON JOB RUNNING IN USER MODE", so not in kernel mode? It seems to write stuff out (to disk, or the console), since it can wait.

Enough time spent on this; have to go do other things. Jnc (talk) 16:32, 14 August 2023 (CEST)

I don't know what the CORE or SYS jobs do, but you're probably right that the CORE job manages dirty pages and other memory book-keeping. It's the same as the corresponding Unix swapper in that it runs in kernel mode and out of the kernel executable.

I have seen some references to things handing off tasks so the SYS job. I think it runs in user mode, and ITS can't make system calls from kernel mode (I forgot what the mode is called on the 10). So that's why it's needed.

The SYS job is also what you get if you create a new job called SYS, and it's core image is that of ITS (the monitor). Akin to /dev/kmem in Unix.

Larsbrinkhoff (talk) 16:40, 14 August 2023 (CEST)

'Exec mode' is the term I usually see. That's official DEC terminology - 'executive' and 'user' modes (only, on the KA10 - later machines had more). Yes, not being able to do system calls from inside the system would explain the need for a job. Jnc (talk) 17:00, 14 August 2023 (CEST)

Yes, BSD added a page-writing daemon: from Berkeley Virtual Memory Extensions to the UNIX Operating System:

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

I wish there was a generally-accepted term for such processes. Maybe I'll ask on COFF? Jnc (talk) 18:15, 14 August 2023 (CEST)

Please do! I usually find the discussions interesting, even though they inevitably derail into assorted ramblings.

Also, we have only covered two somewhat narrow environments: Unix and PDP-10. E.g. IBM people most have a plethora of terms for things like these, and then there are many smaller communities. I'll bring it up in some fora and see what falls out. Larsbrinkhoff (talk) 07:40, 15 August 2023 (CEST)

Here's one, maybe: https://wiki.vmssoftware.com/Symbiont Larsbrinkhoff (talk) 11:36, 15 August 2023 (CEST)

Under VMS V4 and later, symbionts operate in a rather strange environment. A symbiont is a detached process (unlike VMS V3, where it was a subprocess of the job controller). However, it lacks several useful things that most processes have: symbionts have no CLI, which means that they can't spawn commands; symbionts are always created with username SYSTEM and one privilege (SETPRV); and symbionts cannot access process-permanent logicals (SYS$INPUT, SYS$OUTPUT, SYS$ERROR) the way other processes can. https://www.digiater.nl/openvms/freeware/v80/execsymb/freeware_readme.txt Larsbrinkhoff (talk) 11:44, 15 August 2023 (CEST)

Nothing too thrilling from IBM land so far: "On MVS, they are called "started tasks". There could also be some overlap with what MVS calls "subsystems". Larsbrinkhoff (talk) 17:33, 15 August 2023 (CEST)

I've been too busy with a huge project Ulli started, to organize the DEC disks, to do anything with this. Soon! If you're up for it, it might be useful to look at the ITS core job and see exactly what it does. My hypothesis that it writes out 'dirty' pages is just a guess. Jnc (talk) 18:44, 15 August 2023 (CEST)

Good idea, I'll try to do that. What we need is a Hacks and Implementation of the ITS Operating System with a cute dragon mascot. Larsbrinkhoff (talk) 08:11, 16 August 2023 (CEST)

I looked at ITS 1.5 Reference Manual, and at one point (see "4.3 The Core Allocator"), it had the work of 'shuffling' processes around in memory ('the big BLT') to coalesce free space (life before paging :-), and making room for someone who needed a block. So, much like the UNIX 'swapping' process. If ITS used a process to write out 'dirty' pages (unlike Multics), it seems that the CORE job would have been the natural place to do it. Jnc (talk) 13:48, 16 August 2023 (CEST)

I found both SYS and CORE is pretty well explained in SYSDOC;USR > Checking the code in SYSTEM; CORE >, I see once instance of writing dirty pages to disk, but not much more. Shuffling is still being done to maintain continuous physical memory regions. Larsbrinkhoff (talk) 14:53, 17 August 2023 (CEST)

Interesting. I wonder whose job it is to write dirty process memory pages to disk, then, if not the core job? Is it done as part of page fault handling, like Multics? Maybe it's such a simple task that that small amount of code you see there is all that it takes?

I note that SYSDOC;USR > says that both the SYS and CORE jobs run in Exec mode - which makes sense, they can use the Exec page tables - so, between that, and the code being built into the system, I think they both qualify as what I've been calling 'system processes' (I'll get to COFF about that soon, I promise :-); definitely not ordinary daemons!

Good find on that SYSDOC file, I'll add it to the article. Jnc (talk) 15:43, 17 August 2023 (CEST)

Kernel X's

It sounds like 'kernel X' (where 'X' is the abstraction provided by the OS in question) is the preferred term for abstractions that do system functions; 'kernel thread' would be the preferred term in OS's which have threads. I'm going to go with 'kernel process' as the article name, because in the first systems that used these things, they provided processes. So, I'll crank out the kernel process article at some point, and cover kernel threads there. Jnc (talk) 17:05, 15 December 2023 (CET)