<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 15, 2023 at 7:21 AM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 14, 2023 at 5:17 PM Clem Cole <<a href="mailto:clemc@ccc.com" target="_blank">clemc@ccc.com</a>> wrote:<br>
> I don't know of a standard name.   We used to call the kernel processes or kernel threads also.<br>
<br>
I've heard all combinations of (system|kernel) (thread|task|process),<br>
all of which mean more or less the same thing: something the kernel<br>
can schedule and run that doesn't have a userspace component, reusing<br>
the basic concurrency primitives in the kernel for its own internal<br>
purposes. I'm not sure I've heard "kernel daemon" before, but<br>
intuitively I'd lump it into the same category unless I was told<br>
otherwise (as Noel mentioned, of course Berkeley had the "pageout<br>
daemon" which ran only in the kernel).<br></blockquote><div><br></div><div>FreeBSD (and likely others) have extended this to allow kernel</div><div>threads that we loosely call daemons as well. FreeBSD has APIs</div><div>for creating a kernel-only threads and processes...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br>
> ᐧ<br>
<br>
I remember reading a paper on the design of NFS (it may have been the<br>
BSD paper) and there was a note about how the NFS server process ran<br>
mostly in the kernel; user code created it, but pretty much all it did<br>
was invoke a system call that implemented the server. That was kind of<br>
neat.</blockquote><div><br></div><div>I recall discussions with the kernel people at Solbourne who were bringing up</div><div>SunOS 4.0 on Solbourne hardware about this. nfsd was little more than an N way</div><div>fork followed by the system call. It provided a process context to sleep in, which</div><div>couldn't be created in the kernel at the time. I've not gone to the available SunOS</div><div>sources to confirm this is what's going on.</div><div><br></div><div>I'd thought, though, that this was the second nfsd implementation. The first one</div><div>would decode the requests off the wire and schedule the I/O. It was only when</div><div>there were issues with this approach that it moved into the kernel. This was mostly</div><div>a context switch thing, but as more security measures were added to the system</div><div>that root couldn't bypass, NFS needed to move into the kernel so it could bypass</div><div>them. See getfh and similar system calls. I'm not sure how much of this was</div><div>done in SunOS, I'm only familiar with the post 4.4BSD work...</div><div><br></div><div>Warner</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">        - Dan C.<br>
<br>
> On Thu, Dec 14, 2023 at 4:48 PM Noel Chiappa <<a href="mailto:jnc@mercury.lcs.mit.edu" target="_blank">jnc@mercury.lcs.mit.edu</a>> wrote:<br>
>> So Lars Brinkhoff and I were chatting about daemons:<br>
>><br>
>>   <a href="https://gunkies.org/wiki/Talk:Daemon" rel="noreferrer" target="_blank">https://gunkies.org/wiki/Talk:Daemon</a><br>
>><br>
>> and I pointed out that in addition to 'standard' daemons (e.g. the printer<br>
>> spooler daemon, email daemon, etc, etc) there are some other things that are<br>
>> daemon-like, but are fundamentally different in major ways (explained later<br>
>> below). I dubbed them 'system processes', but I'm wondering if ayone knows if<br>
>> there is a standard term for them? (Or, failing that, if they have a<br>
>> suggestion for a better name?)<br>
>><br>
>><br>
>> Early UNIX is one of the first systems to have one (process 0, the "scheduling (swapping)<br>
>> process"), but the CACM "The UNIX Time-Sharing System" paper:<br>
>><br>
>>   <a href="https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf" rel="noreferrer" target="_blank">https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf</a><br>
>><br>
>> doesn't even mention it, so no guidance there. Berkeley UNIX also has one,<br>
>> mentioned in "Design and Implementation of the Berkeley Virtual Memory<br>
>> Extensions to the UNIX Operating System":<br>
>><br>
>>   <a href="http://roguelife.org/~fujita/COOKIES/HISTORY/3BSD/design.pdf" rel="noreferrer" target="_blank">http://roguelife.org/~fujita/COOKIES/HISTORY/3BSD/design.pdf</a><br>
>><br>
>> where it is called the "pageout daemon".("During system initialization, just<br>
>> before the init process is created, the bootstrapping code creates process 2<br>
>> which is known as the pageout daemon. It is this process that .. writ[es]<br>
>> back modified pages. The process leaves its normal dormant state upon being<br>
>> waken up due to the memory free list size dropping below an upper<br>
>> threshold.") However, I think there are good reasons to dis-favour the term<br>
>> 'daemon' for them.<br>
>><br>
>><br>
>> For one thing, typical daemons look (to the kernel) just like 'normal'<br>
>> processes: their object code is kept in a file, and is loaded into the<br>
>> daemon's process when it starts, using the same mechanism that 'normal'<br>
>> 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<br>
>> the kernel to start daemons (on early UNIXes, /etc/rc is run by the 'init'<br>
>> process, not the kernel); daemons interact with the kernel through system<br>
>> calls, just like 'ordinary' processes; the daemon's process runs in 'user'<br>
>> CPU mode (using the same standard memory mapping mechanisms, just like<br>
>> blah-blah).<br>
>><br>
>> 'System processes' do none of these things: their object code is linked into<br>
>> the monolithic kernel, and is thus loaded by the bootstrap; the kernel<br>
>> 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 routines<br>
>> directly; they run in kernel mode, using the same memory mapping as the<br>
>> kernel itself; etc, etc.<br>
>><br>
>> Another important point is that system processes are highly intertwined with<br>
>> the operation of the kernel; without the system process(es) operating<br>
>> correctly, the operation of the system will quickly grind to a halt. The loss<br>
>> of ordinary' daemons is usually not fatal; if the email daemon dies, the<br>
>> system will keep running indefinitely. Not so, for the swapping process, or<br>
>> the pageout daemon<br>
>><br>
>><br>
>> Anyway, is there a standard term for these things? If not, a better name than<br>
>> 'system process'?<br>
>><br>
>>         Noel<br>
</blockquote></div></div>