merlin@hqda-ai.UUCP (01/24/87)
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.
COMMENTS --> postnews
FLAMES --> mail
(I do read flame mail, but there's no reason everyone else has to.)
1. Device driver for the IOMEGA Bernoulli Box:
I have a twin 20-meg bernoulli here. Sure would be nice to
be able to use it... Seriously, the bernoulli is good, reliable,
has a large capacity, and is relatively fast. Good candidate for
a device driver.
I'd like to have partitions (Sys5 slices) on the drive. With
a floppy, there's no sense in partitioning the thing. It's just
not big enough to worry about. But 20 megs is quite enough to do
it with, and I want partitions for another extension.
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.
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.
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
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.
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.
Assuming that we can reassign processes, we need a place to
put them. The partition scheme provides an efficient place (a
block device) for this storage. I would prefer to swap the text
portion of a process out first. Only swap the data/stack segment
if the text didn't free up enough memory. Reason: the stack area
is read-write, so we must write it to swap space, and read it back
in. The code segment is (presumably) read-only, so there's no
need to write it out. It can be reloaded from the executable
file.
5. Provide SIGSTOP/SIGTSTP and job control, ala 4.xBSD
Modifications required to the terminal/keyboard drivers.
Also, the shell would have to be told about this, to make it
useful. This is not a particularly great idea unless 4 is also
implemented. No point in background jobs unless there's memory to
hold them. (God, I miss VM hardware :-( )
Well, that's my list so far. I should say that my machine is an
AT. This set of extensions is probably too much for the
garden-variety PC, but I've got the CPU cycles to support this
sort of stuff (I hope).
Why bother with all this? Why not just buy Sys-V for the PC?
BECAUSE I WANT THE SOURCE, AND I DON'T LIKE AT&T. Also, I intend
to run uucp mail and usenet news on this beast, and it'll need all
the help it can get.
Points for discussion:
a) Are these useful?
b) Can they be done?
c) Does anyone want them?
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.
--
David S. Hayes, The Merlin of Avalon
PhoneNet: (202) 694-6900
ARPA: merlin%hqda-ai.uucp@brl-smoke
UUCP: ...!seismo!sundc!hqda-ai!merlinrmtodd@uokmax.UUCP (01/25/87)
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
allbery@ncoast.UUCP (01/26/87)
As quoted from <252@hqda-ai.UUCP> by merlin@hqda-ai.UUCP (David S. Hayes): +--------------- | a) Are these useful? | b) Can they be done? | c) Does anyone want them? | 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. +--------------- I dunno about you, but I intend to move my UNaXcess development environment to MINIX as soon as I get my hands on it and port some micro-variant of Emacs to it; at which point I'll be able to get cracking on the protocol module business and churn out programs to handle UUCP, Xmodem, Kermit, FidoNet, et cetera. Anyway, if AT&T, as stuffy as they are, will allow you to post diffs to Sys5 utilities, Prentice-Hall and Mr. Tanenbaum should be at least as lenient, given the nature of MINIX. ++Brandon -- ____ ______________ / \ / __ __ __ \ Brandon S. Allbery <backbone>!ncoast!allbery ___ | /__> / \ / \ aXcess Co., Consulting ncoast!allbery@Case.CSNET / \ | | `--, `--, 6615 Center St. #A1-105 (...@relay.CS.NET) | | \__/ \__/ \__/ Mentor, OH 44060-4101 \____/ \______________/ +1 216 781 6201
mcvoy@uwvax.UUCP (01/28/87)
In article <1953@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >I dunno about you, but I intend to move my UNaXcess development environment >to MINIX as soon as I get my hands on it and port some micro-variant of Emacs >to it; at which point I'll be able to get cracking on the protocol module >business and churn out programs to handle UUCP, Xmodem, Kermit, FidoNet, et >cetera. I'm a little amused at all the *proposed* activity. Either you all have jobs that encourage non-relevent hacking or you're going to forget your social life (you have one, right?) or you're tootin' that horn a little loud, methinks. Or maybe you're just orders of magnitude faster than me (not too hard, I guess). First of all, try porting some random programs between SV and 4BSD. Rn, uucp, dump/restore are all fun. You'll find it a less than trivial task. And this you can do on your 16Mhz 68020 w/ ~1Gig of disk... Now, try porting ls to minix. By the time you have pulled all the unused or meaningless parts of ls out, you could have probably rewritten it from scratch. Now try cp. Now try vi. Chuckle. Remember, you're working on a 8808 w/ a sl-o-o-o-w compiler/OS/CPU. Runs at about 4Mhz. Uses floppies (whirr, whirr). Runs a msg-based system (means nice code but slooow throughput. The MACH people have yet to _prove_ otherwise, thought they sure talk a lot :-) Still here, huh? Now, remember that AT&T code is not public domain (see below). Things like the protocol that is used in UUCP are proprietary, not public domain. Any port of UUCP that shows up in public domain is _extremely_ suspect. I know of one port where the author claims to have done it all by looking at logfiles. You might ask him how long it took (lauren@vortex.uucp). AT&T can always decide to make an example to slow down theft. >Anyway, if AT&T, as stuffy as they are, will allow you to post diffs to Sys5 >utilities, Prentice-Hall and Mr. Tanenbaum should be at least as lenient, ^^^ That's Dr. Tanenbaum. >given the nature of MINIX. Geez. You really live with your head in the clouds. Post diffs? Chuckle. A) The diffs would be so huge, you might as well post the entire program. B) This is a cut-and-dried case of license violation. You would deserve to lose it. Remember, AT&T is the business to make $money$. Not to support your toys. Geez. -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
anderson@uwmacc.UUCP (01/28/87)
In article <3166@rsch.WISC.EDU>, mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: Forgive me, please, as it's fairly far from Minix, but since Larry's a fellow colleague here at the Athens of the Midwest (yes, it really did say that of Madison in the Yellow Pages years ago!), I can scarcely believe my eyes: > >Anyway, if AT&T, as stuffy as they are, will allow you to post diffs to Sys5 > >utilities, Prentice-Hall and Mr. Tanenbaum should be at least as lenient, > ^^^ That's Dr. Tanenbaum. > >given the nature of MINIX. There is a *long* tradition at Wisconsin of referring to all male faculty, irrespective of their degress, as "Mr." I believe it came about originally as a kind of pseudoegalitarian snobbism cadged from our betters at Harvard. Doubtless those of even greater antiquity than your informant can say more definitely. Matters of title and status are handled differently from place to place, and need not concern us further. But I could not let the usenet readership be left with the idea that we are snobs here WRT titles and degrees. Why, just yesterday I ran into a world-famous physicist friend in the basement of our building, a full professor of great distinction but having no PhD; as usual, he was spouting obscenities in Italian in a *most* unpretension way. He goes by Mr. or Prof. <name>. Sensible! Nota bene:-) -- ==ARPA:==============anderson@unix.macc.wisc.edu===Jess Anderson====== | UUCP: {harvard,seismo,topaz, (avoid ihnp4!) 1210 W. Dayton | | akgua,allegra,usbvax}!uwvax!uwmacc!anderson Madison, WI 53706 | ==BITNET:======================anderson@wiscmacc===608/263-6988=======
gwyn@brl-smoke.UUCP (01/28/87)
The main thing I wish MINIX would have is POSIX conformance. Just about the time we were getting the vendors to bring their variations on UNIX all into agreement, this one had to come along. Fortunately the likelihood of its being heavily hacked (like UNIX in the old days) reduces the chances that commercial application software developers will really have to support it.
ee161aba@sdcc18.UUCP (01/29/87)
In article <3166@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: (whilst picking on allbery@ncoast (Brandon Allbery) >Now, remember that AT&T code is not public domain (see below). Things like >the protocol that is used in UUCP are proprietary, not public domain. Any >port of UUCP that shows up in public domain is _extremely_ suspect. I >know of one port where the author claims to have done it all by looking >at logfiles. You might ask him how long it took (lauren@vortex.uucp). >AT&T can always decide to make an example to slow down theft. You're right. UUCP doesn't work either! I say it's time to junk the silly thing and build something that is a) simple and reliable b) public-domain so we poor fools without source licences can make it work UUCP is really a pretty simple program when you get down to what it is actually used for, moving files out of one directory into another on another machine. I'm going to get started on some hacks that will allow kermit to go in and zip files back and forth out of directories that are set up uucp style for compatibility. > >>Anyway, if AT&T, as stuffy as they are, will allow you to post diffs to Sys5 >>utilities, Prentice-Hall and Mr. Tanenbaum should be at least as lenient, > ^^^ That's Dr. Tanenbaum. >>given the nature of MINIX. > >Geez. You really live with your head in the clouds. Post diffs? Chuckle. > >A) The diffs would be so huge, you might as well post the entire program. > >B) This is a cut-and-dried case of license violation. You would deserve > to lose it. > >Remember, AT&T is the business to make $money$. Not to support your >toys. Geez. Spoilsport! You're mixing your subjects here. Which are you talking about, MINIX license violations or AT&T license violations? If you're talking about AT&T, what does that have to do with anything here? If someone takes the UUCP code and modifies it to run under Minix, we've got a copyright violation, not a license violation. No, AT&T is not in business to support my toys. However, AT&T does not own Minix, nor does it have any right to tell me what I can do with my toys provided I don't step on AT&T's toes. I think Dr. Tanenbaum is the person to refer these kinds of questions to. In the meantime, I'll wait on writing vaporware until I get to *see* Minix in action. If you're so upset by a little enthusiasm, go soak your head and stop reading this newsgroup. The blue sky people here have got work to do. >-- >Larry McVoy mcvoy@rsch.wisc.edu, > {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy >"They're coming soon! Quad-stated guru-gates!" Cheers, David L. Smith Send here --> {ucbvax, ihnp4}!sdcsvax!man!sdeggo!dave {ucbvax, ihnp4}!sdcsvax!sdcc18!ee161aba "Consistency is the hobgoblin of little minds"
davidsen@steinmetz.UUCP (01/30/87)
In article <252@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: > >1. Device driver for the IOMEGA Bernoulli Box: > Great! > >2. Provide a way to format disks without going into MS-DOS. > The ROM firmware has a format entry via software interrupt. You can use that for a starting place. > >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. If you allocate a full 64k to data, there is hardware protection: you can't address more than that. This assures that any program which doesn't deliberately set out to cause problems will not modify the code. At the moment it looks as if the model used is code+data in one 64k lump. That precludes sharing. Hopefully this limitation will be fixed. > >4. Swap processes > ... discussion trimmed ... > >5. Provide SIGSTOP/SIGTSTP and job control, ala 4.xBSD > After using virtual terminals ala Xenix and Microport, you will be more willing to forego job control (it's still useful). > ... some trimmed ... > > Why bother with all this? Why not just buy Sys-V for the PC? >BECAUSE I WANT THE SOURCE, AND I DON'T LIKE AT&T. Also, I intend ^ ^ technical reason ---| |--- your privilege >to run uucp mail and usenet news on this beast, and it'll need all >the help it can get. Why? Those things seem to run just fine under Microport ($160) with no source, tricks, fiddling, etc. Summary: MINIX is a great system, and will be lots of fun to play with. It is not a candidate to replace UNIX in most places because most people don't know how to tinker with an o/s, and those of us who do have no desire to do it for fun. Therefore, I see no reason to run down UNIX because you don't like AT&T, MINIX is a solution to another problem. -- bill davidsen sixhub \ ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen chinet / ARPA: davidsen%crdos1.uucp@crd.ge.com (or davidsen@crd.ge.com)
allbery@ncoast.UUCP (01/31/87)
As quoted from <3166@rsch.WISC.EDU> by mcvoy@rsch.WISC.EDU (Lawrence W. McVoy): +--------------- | In article <1953@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: | >I dunno about you, but I intend to move my UNaXcess development environment | >to MINIX as soon as I get my hands on it and port some micro-variant of Emacs | >to it; at which point I'll be able to get cracking on the protocol module | >business and churn out programs to handle UUCP, Xmodem, Kermit, FidoNet, et | >cetera. | | I'm a little amused at all the *proposed* activity. Either you all have | jobs that encourage non-relevent hacking or you're going to forget your | social life (you have one, right?) or you're tootin' that horn a little | loud, methinks. Or maybe you're just orders of magnitude faster than | me (not too hard, I guess). +--------------- Most of it is 75% or more done. It's ``proposed'' because my development environment is a P/60 with hardware problems (crashes 3-5 times a day! )-: -- which is why I want to get MINIX up. After that, a revamp of UA-Conf, of UA-Mail aka IMS, of UA-Spool aka pqs, and some other projects which are based on existing code used in different ways (lifting the menus out of UA-Conf and creating a menu shell, for example). Show me a computer that will stay up long enough and I'll show you some interesting programs... +--------------- | First of all, try porting some random programs between SV and 4BSD. Rn, | uucp, dump/restore are all fun. You'll find it a less than trivial task. | And this you can do on your 16Mhz 68020 w/ ~1Gig of disk... Now, +--------------- I'm quite good at this, thank you. Just avoid the sockets -- I don't have sVr3 (yet). 12MHz 68020, 280MB disk, 3MB RAM. :-) +--------------- | try porting ls to minix. By the time you have pulled all the unused | or meaningless parts of ls out, you could have probably rewritten it from | scratch. Now try cp. Now try vi. Chuckle. Remember, you're working +--------------- Ls -- this is hard? And what parts are useless? (Aside from the modify vbs. create vs. access time, there being only the modify time in MINIX.) Cp -- trivial. Vi -- this is not a program, it's a kludge. Give me Emacs any day. +--------------- | Now, remember that AT&T code is not public domain (see below). Things like | the protocol that is used in UUCP are proprietary, not public domain. Any | port of UUCP that shows up in public domain is _extremely_ suspect. I | know of one port where the author claims to have done it all by looking | at logfiles. You might ask him how long it took (lauren@vortex.uucp). | AT&T can always decide to make an example to slow down theft. +--------------- I can write a UUCP by throwing random garbage at a uucico until I get a response, via trial-and-error. Normally, it'd be ``an unbearable trial and a colossal error'', but with no other choice I could do so and produce a wor- king product. Eh? +--------------- | >Anyway, if AT&T, as stuffy as they are, will allow you to post diffs to Sys5 | >utilities, Prentice-Hall and Mr. Tanenbaum should be at least as lenient, | ^^^ That's Dr. Tanenbaum. | >given the nature of MINIX. | | Geez. You really live with your head in the clouds. Post diffs? Chuckle. | | A) The diffs would be so huge, you might as well post the entire program. | | B) This is a cut-and-dried case of license violation. You would deserve | to lose it. | | Remember, AT&T is the business to make $money$. Not to support your | toys. Geez. +--------------- Introducing comp.bugs.sys5. Look it up sometime. Usenet is not dead yet as a result. No, diffs need not be huge; just recently a discussion of a stdio bug took place; a workaround for binary systems and a description of the problem in the source were posted. (Although I admit that the diffs are usually found in the BSD newsgroup -- but a lot of BSD Unix is AT&T code. Think about it.) Re: AT&T not supporting our ``toys'' (i.e. broken Unix System V): if they won't support it, they'll lose their money to mt. Xinu. AT&T isn't God. ++Brandon -- ++Brandon (Resident Elf @ ncoast.UUCP) ____ ______________ / \ / __ __ __ \ Brandon S. Allbery <backbone>!ncoast!allbery ___ | /__> / \ / \ aXcess Co., Consulting ncoast!allbery@Case.CSNET / \ | | `--, `--, 6615 Center St. #A1-105 (...@relay.CS.NET) | | \__/ \__/ \__/ Mentor, OH 44060-4101 \____/ \______________/ +1 216 781 6201
henry@utzoo.UUCP (Henry Spencer) (02/01/87)
> You're right. UUCP doesn't work either! I say it's time to junk the silly > thing... UUCP is really a pretty simple program ... Don't underestimate the difficulty of getting a good serial protocol. Given adequate CPU crunch on both ends, UUCP will run high-speed lines at near theoretical maximum throughput for hours on end, even in the presence of substantial error rates. This is *not* trivial. Not grossly difficult, either, but to do it takes knowledge and effort. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
dan@prairie.UUCP (Daniel M. Frank) (02/01/87)
In article <1169@steinmetz.steinmetz.UUCP> davidsen@kbsvax.UUCP (william E Davidsen) writes: >In article <252@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: >>to run uucp mail and usenet news on this beast, and it'll need all >>the help it can get. > >Why? Those things seem to run just fine under Microport ($160) with no >source, tricks, fiddling, etc. Those things run just fine under Microport because: a) Microport COMES with AT&T uucp already. b) Microport has a large model compiler. Most of the news programs are VERY large, and will not compile and link under small model, let alone the Minix `tiny model' compiler. -- Dan Frank ARPA: dan@db.wisc.edu ATT: (608) 255-0002 (home) UUCP: ... uwvax!prairie!dan (608) 262-4196 (office) SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006
cds@atelabs.UUCP (02/05/87)
In article <411@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: > b) Microport has a large model compiler. Most of the news programs > are VERY large, and will not compile and link under small model, > let alone the Minix `tiny model' compiler. > I am posting this using a PC-XT running PC/IX. This is sufficient to prove that news (2.11) will compile and link under the small model. PC/IX has no large model compiler. It does, however, support split I and D space as does Minix. Unfortunately, Minix's compiler doesn't support split I and D. So, to run news under Minix you will have to cross compile from PC/IX or some other environment. You will also have to figure out some way to communicate with other Unix or Minix machines. -- Dave Shanks ..!tektronix!tessi!atelabs!cds AT&E Laboratories cds@atelabs.UUCP 1400 NW Compton Suite 300 (503) 690-2000 Beaverton, OR 97006
nick@pedsgo.UUCP (02/07/87)
In article <252@hqda-ai.UUCP> merlin@hqda-ai.UUCP writes: >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 ^^^^^^^^^^^ I think you mean that processes shouldn't be allowed to modify their segment registers, but the OS should. (Memory Manager Duty) >registers. Really, they can't even *refer* to the segment >registers. The only reason for doing that is to reference ^^^^^^^^^^ I thought the 286 had impied references via CS for code, DS for data and SS for stack... What are you talking about? 8-) >something via the segment register. If the segment register might >change later, that would invalidate the reference. The key segment registers is that you modify the register after moving what it points to, a certain displacement that you modified the register by... > 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. > > Assuming that we can reassign processes, we need a place to >put them. The partition scheme provides an efficient place (a >block device) for this storage. I would prefer to swap the text >portion of a process out first. Only swap the data/stack segment >if the text didn't free up enough memory. Reason: the stack area >is read-write, so we must write it to swap space, and read it back >in. The code segment is (presumably) read-only, so there's no >need to write it out. It can be reloaded from the executable >file. Not too good, since your swap device will swap out stuff in one contiguous blob, while your executable file MAY be scattered all about makeing swap time go through the roof! Also, if you go off and swap out (via your proposed "get rid of the text segment first" technique) a process, your disk arm has to read in a new text segment and then seek from the filesystem of the executable file all the way to the swap area and read in the code and data segements... And now that the text segment is gone, all other processes that shared that code (shells, gettys) have lots of useless memory being used by their data segments... >Also, I intend >to run uucp mail and usenet news on this beast, and it'll need all ^^^^ Sorry, this too is under AT&Ts domain... >the help it can get. > > David S. Hayes, The Merlin of Avalon > PhoneNet: (202) 694-6900 > ARPA: merlin%hqda-ai.uucp@brl-smoke > UUCP: ...!seismo!sundc!hqda-ai!merlin *** Standard disclaimer applies... All I say is some of what I mean and ***** *** not what other people or corporations mean, although they may... ***** ____________ / _________/_ "Haven't had a dream in a long time, / / / / Seems the luck I've had, /__/________/ / Could turn a good man, bad, Concurrent /__________/ So for once in my life, Computer Corporation Let me get what I want, Xelos Development Lord knows it would be the first time" - The Smiths Nicolai Kosche ********************************************** petsd!pedsgd!nick