Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!ames!haven.umd.edu!udel!mmdf
From: wjb@cogsci.cog.jhu.edu
Newsgroups: comp.os.minix
Subject: Re: Arrrrghhh... Who needs an operating system anyway!!!!!
Message-ID: <57554@nigel.ee.udel.edu>
Date: 30 Jun 91 00:40:09 GMT
Sender: mmdf@ee.udel.edu
Lines: 50


>I have just upgraded my ageing distribution of 1.2 minix to 1.3 and what do
>I find.... The _port_in and _port_out have been moved out of klib88.s and
>into libc.a. Why bother to have an operating system in the first place if
>you are going to allow users to access the hardware?????

	Since the 8088 doesn't have any mode where the INP or OUT
instructions are disallowed it really doesn't matter whether they are in
libc.a or not.  Since you can always insert them directly into your binaries
or write your own routines in assembler there wasn't any reduction in the
security of the system.

>I always worked to a very simple rule when deciding if a routine belonged
>in the kernel or elsewhere. I ask myself "Does it access hardware?" If the
>answer is yes then it goes in the kernel... NO EXCEPTIONS. If the answer is
>no then it's a toss up as to wether it belongs in a user process (daemon)
>or in a system task. Like mm and fs in minix.
>
>What is going on here? Have I got hold of the wrong end of the stick here
>or is 1.3 the biggest mistake since VMS??

	It isn't alway practical or reasonable to write new kernel code for
every possible operation which you might want to do to hardware.  A good
example would be the code that reads the battery-backed clock on the PC.  Is
there any reason to have this code linked into the kernel and permanently
resident in memory?  It is likely to only get executed once at boot time
from the the /etc/rc script.  Actually, in 1.3, I believe that access was
made via the /dev/port file and that can be protected to any level that you
want.  In the protected mode version for the 80286, the protection even
means something.

	Do you also object to the /dev/mem or /dev/kmem files?  Are IO port
addresses all that different from arbitrary physical memory addresses?  Just
as dangereous and sometimes just as useful.  One of the original strong
points of Unix, was that it tried to provide a small general system.  It does
90% of the job because that is in fact more then most people really need.
Sometimes there just isn't any clean elegant way (or it isn't worth spending
the time) to do something.  Take a look at the "ps" command.  Until fairly
recently (3-4 years), on every Unix system it got its information from
reading the symbol table of the kernel and groveling through /dev/kmem.  It
wasn't completely accurate all the time, but quite functional.  Some newer
systems now have system calls or libraries to provide such information, but
they can provide just as inconsistent a view of the system.  (Processes can
be created and/or die during the system call.)

	Rules are a good thing, but sometimes you have to break them.  The
best systems are designed by people who come up with good rules and then
aren't afraid to break them when it is appropriate to do so.

				Bill Bogstad