Newsgroups: comp.os.minix
Subject: Re: Printing to file from kernel
References: <3A3732F7.886CC01F@hotmail.com> <918crj$u4u$1@nnrp1.deja.com>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <3a3813b6@news.isc.rit.edu>
Date: 13 Dec 2000 19:26:30 -0500
X-Trace: 13 Dec 2000 19:26:30 -0500, grace.isc.rit.edu
Lines: 55
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.edu.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.mel.connect.com.au!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.edu.au comp.os.minix:36314

In article <918crj$u4u$1@nnrp1.deja.com>,  <eliason@my-deja.com> wrote:
>In article <3A3732F7.886CC01F@hotmail.com>,
>  Amardeep Chohan <acwinter@hotmail.com> wrote:
>> How can I print to a file from kernel?
>
>luckily, i happen to be in the mood to pontificate!  here
>is the simplest suggestion i can make.

<snip lots of good stuff--have the kernel fill in a structure in userland,
and have userland stuff write a file>

>you may find that the system deadlocks, which might happen when
>the system task is sending the reply to the user process, if the
>user process runs out of it time quantum and gets put at the end
>of the round robin.  in that case the system task won't be able
>to deliver the reply message...  this might lock things up, or
>maybe all the other processes will eventually block until the print-
>out process becomes eligible again, in which case there will be
>no deadlock.

Under Minix, this cannot happen, due to the way messages work.  A user
process can only do a sendrec--an atomic send and receive, with the
receive part limited to receiving from the server which the send sent
to.  Messages are passed by directly copying the data from the sender's
send buffer to the receiver's receive buffer, which doesn't require
the receiver's process to be running at the time.  (There are only two
possibilities, actually--before the message is passed, either the
receiver is blocked, waiting for a message, or the sender is blocked,
waiting for the receiver to receive.  Afterwards, both can continue.)

Much of the confusion may stem from vocabulary difficulties.  In Minix:
a process is a userland thing;
a server accepts messages from processes and "does" system calls;
a task accepts messages from hardware and from servers and does I/O (and
     perhaps a few other psuedo-I/O types of things);
what should be called the kernel simply passes messages, saves and
     restores process states, and distributes interrupts to device
     drivers.  (This all happens only in response to interrupts and
     software traps.)  The term kernel, however, has been applied to
     this part and the collection of tasks, which share a namespace.
     Further, some people (including me, I admit) sometimes refer to
     the entire set of servers, tasks, and kernel stuff as the kernel,
     since this corresponds to what actually is the kernel in most
     monolithic operating systems and since there isn't really a handy
     word to refer to the sum of the non-userland stuff.

I think we really need to invent some words to precisely and distinctly
define what "kernel" now sometimes signifies.  Alas, I'm not feeling
too creative at the momment; perhaps because it's past suppertime (and
I've not yet eaten supper).

>-ade

-- 
Andrew Erickson
