Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!okstate!uokmax!rmtodd
From: rmtodd@uokmax.UUCP
Newsgroups: comp.os.minix
Subject: Re: MINIX extensions
Message-ID: <422@uokmax.UUCP>
Date: Sun, 25-Jan-87 00:56:25 EST
Article-I.D.: uokmax.422
Posted: Sun Jan 25 00:56:25 1987
Date-Received: Sun, 25-Jan-87 10:40:17 EST
References: <252@hqda-ai.UUCP>
Organization: University of Oklahoma, Norman, OK
Lines: 91
Keywords: shared swapped bernoulli jobs
Summary: Sounds good to me

In article <252@hqda-ai.UUCP>, merlin@hqda-ai.UUCP (David S. Hayes) writes:
> 
>      Well, Tanenbaum's book hasn't even had time to let the ink
> dry, and here I am looking for extensions.  I really love the idea
> of a more-or-less public domain OS, but it needs some work to be
> really useful.  Here's a few suggestions.
> 1. Device driver for the IOMEGA Bernoulli Box:
I don't have one, but I'm sure any MINIX user with one would want to be
able to run a MINIX partition on it.
> 2. Provide a way to format disks without going into MS-DOS.
>      My system isn't used for MS-DOS, or won't be, as soon as I
> can get a hold of MINIX.  I'd like to be able to format disks.  I
> think the disk drivers should have another IOCTL for this.
>      A format ioctl could chew up lots of space in the kernel, and
> it really won't get used that often.  I think an ioctl to write a
> raw track, including all the format bytes, would be in order.  It
> would be relatively small.  The real work of figuring out how to
> format a disk can be left to a user-level program.
Sounds like a good and useful utility to have. The raw-track
write ioctl sound good, although you may need a couple of other ioctls
for seek-to-track and the like. 
> 3. Share program text
> 
>      I see no reason why the same program should have to be loaded
> multiple times.  The code segment is assumed to be read-only.  I
> know there's no hardware protection for this, but in general I
> think it's a safe bet, and it would free up memory.  Memory seems
> to be the limiting factor in MINIX.
In your standard PC there isn't any memory protection for *anything* :-)
I seriously doubt that it'll cause any problems, though.  As long as programs
are well behaved and you don't have an assembly-lang prog doing weird things
with its code seg. it ought to be OK.  I assume that in the code produced by
the C compiler data-storage operations affect only the data seg, so that
you can't even accidentally write self-modifying code in MINIX C.
> 4. Swap processes
>      This is why I wanted partitions.  At present, when MINIX runs
> out of core, no more process creations are allowed.  Two things
> can be done about this:
>      a) Rearrange processes in memory, to free up the unused space
> that may be lurking between processes.  This may work, provided
> that MINIX processes are allowed to fiddle with their segment
------------------------^
shouldn't that be "aren't"?
> registers.  Really, they can't even *refer* to the segment
> registers.  The only reason for doing that is to reference
> something via the segment register.  If the segment register might
> change later, that would invalidate the reference.
My understanding from what I've seen on the net (yes, my copy of the book
hasn't come yet) is that in MINIX programs you've got two segments, one
code and one data/stack combined.  Presumably whenever a context switch to
the process occurs CS gets set to the codeseg and DS and SS to the other
seg. and the process' code just does its MOVs and CALLs without having to
meddle with segment regs or prefixes.  "Well-behaved" programs should cause
no problem.
Of course, the whole thing would be hopelesly complicated if MINIX allowed
large-memory-model programs, because then whenever you moved the data segment
you'd have to fiddle with all long pointers that pointed to data.  Fortunately
we don't have that problem, yet.  Given a choice between adding large-memory
model capability or swapping, I'd definitely go for swapping.
>      b)  Swap processes, or portions thereof, out to disk.  Not so
> good on floppy, but acceptable on a bernoulli or winchester.  This
> isn't really feasible unless (a) above is also ok.  
Funny you should mention this -- I'd been thinking along the same lines of
how swapping would be a good extension to MINIX.  Hadn't thought about how
you don't really need to write out the code seg, though.  That could really
cut down on swap space requirements.  Of course, you'd have to keep track
of which file the code images came from, but that shouldn't add too much
overhead.  It probably would be a good idead to add some sort of locking
facility, so that any program that tries to write to an executing file gets
a "Text Busy" error code, a la UNIX.

> 5. Provide SIGSTOP/SIGTSTP and job control, ala 4.xBSD
Again, I was thinking along the same lines.  I agree, it may not be useful
without swapping.  (I just love Berkley job control).
> Points for discussion:
> a)   Are these useful?
yes
> b)   Can they be done?
probably
> c)   Does anyone want them?
I sure do.
> d)   If they are done, how do I publish them without stepping all
>      over Tanenbaum's rights?  I think its OK to publish only the new
>      stuff (you'd still have to pay Prentice-Hall for the basic OS),
>      but I'd like a second, third, and fourth opinion.
That agrees with my understanding of how it works.  It probably wouldn't
hurt to ask Tanenbaum himself just to make sure.
___________________________________________________________________________
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd