wtoomey@gara.une.oz (Warren Toomey) (06/06/89)
In article <2775@munnari.oz>, muller@munnari.oz (Paul Muller) writes: [ about the future design of Minix, and it's direction ] Minix definitely is split between two camps of users: a) Those using it to learn about O/S design b) Those wanting a cheap, good, O/S with source code. For the former group, the source needs to be simple, concise, and well documented. For the latter, anything that's considered `useful'. I believe that Minix 1.2 & Minix 1.3 very adequately satisfy the demands of the academic users. For them, any increase in the size & complexity of Minix would do more harm than good. The IBM-XT here also helps as it is simple, and cheap for academic departments to buy. However, for the latter group, much more can be done with Minix to get it as (current) Unix-compatible as possible. This really means leaving the IBM-XT behind, and moving on to more powerful machines, with larger available memories etc. The port of Minix to the '286, and the Atari ST port are the first steps in this direction. Therefore, I propose that Minix be broken into two parts. One, a simple static version of Minix, such as 1.3, to be used to teach about operating systems, and based on the XT or ST. The other, a continually evolving system, to keep everybody else happy. This should be ported to many machines, like the ST, '286 & '386 etc, and hopefully should mean that all the machine dependencies will reside in only a few files in the kernel/mm/fs/etc. > Minix first and foremost is the poor student's teaching OS. It serves its > purpose above and beyond the call of duty, and that is the point. This is the `academic' Minix. > POSIX compliance is probably important from the point of view of teaching > ideas in a real world sense (we can't always patch the C compiler!). POSIX compatibility should apply to both versions. > The second is the 'upmarket' Minix that everyone seems to think is so > important, why? Most people who got into Minix for reasons other than formal > education just wanted to 'hack around'. > If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO, > etc offerings. They produce different BINARIES for each processor ... Not only did I buy Minix to play with, but also to have a version of Unix with almost full source code, and to be a part of comp.os.minix, where each of us can add to Minix's source code pool, and also help with design ideas, bug reports etc. This is difficult (nay, impossible) with real Unix. At the present point in time, Minix only vaguely resembles current flavours of Unix, and I would really like to see it become as compatible with both the ATT and Berkely flavours of Unix. This has already started with sources such as termcap(3), and the memcpy,bcopy variants. Both flavours of Unix overlap in many areas, and also have extensions which exists in only one flavour. If Minix could be a fusion of both flavours, and keep compatibility with them AND POSIX ( & SVID ?), then we would have an O/S which would be the best of both worlds AND with source. > I like what Bruce and others are doing for Minix, but the seminal idea > of ast's based itself on V7, "because of its simplicity and elegance" and this > is foremost in my mind when I hear talk about changing the listing that will > appear in the back of the second revision of The Book. I agree. The O/S book and `academic' Minix should be kept exactly as is to make teaching O/S as easy as possible. However, a more powerful version of Minix should be allowed to develop too. > What is > needed is some form of arbitration committee to decide what goes in the > upmarket version. This should not just rest on ast's shoulders, I prefer > he gets more time to write his great books! :-) Yes! Andy, 'though, being the founder of Minix, should have the final say on the future of Minix. But a committee of some sorts would take a lot of the load from him. BTW, speaking of Minix design, what about job control and the extra Berkely signals for Minix. This will allow shells etc, to have better control over child processes, and won't be incompatible with the Version 7 & SysV signals - well, perhaps a few! Any ideas, comments? Warren Toomey University of New England Australia. (wtoomey@gara.une.oz)
roberto@cwi.nl (Rob ten Kroode) (06/06/89)
In article <798@gara.une.oz> wtoomey@gara.une.oz (Warren Toomey) writes: >BTW, speaking of Minix design, what about job control and the extra >Berkely signals for Minix. This will allow shells etc, to have better >control over child processes, and won't be incompatible with the >Version 7 & SysV signals - well, perhaps a few! Any ideas, comments? When Minix was just out I added job control and all necessary signals to Minix. I had only one problem: testing it :-) I needed some sort of shell with job control. I had no such (public domain) beast that was small enough to run under minix, and I had no time to write one. I asked Andy some advise, and he told me that he didn't like the idea of job control in Minix. In fact, he isn't too fond of any Berkeleyism (sp?) at all :-( I guess that these kinds of changes/additions shouldn't appear in the vanilla Minix version that should be used as a teaching OS. About the direction of Minix; I think it is impossible to keep only one version. There definitely should be the OS teaching tool: the current version (should be POSIX compatible). Besides that version there will evolve a second version: the Minix for the hackers. A cheap, well written unix system which you can really use for applications. For the latter version Bruce's patches are a good step in the right direction. Comments? -- | Rob ten Kroode (roberto@cwi.nl) | Don't read this !! | "When they said 'sit down' I stood up", Growing up - Bruce Springsteen
dal@syntel.UUCP (Dale Schumacher) (06/09/89)
In article <798@gara.une.oz>, wtoomey@gara.une.oz (Warren Toomey) writes: >In article <2775@munnari.oz>, muller@munnari.oz (Paul Muller) writes: > > [ about the future design of Minix, and it's direction ] [ much about separate teaching and hacking versions deleted ] > >> POSIX compliance is probably important from the point of view of teaching >> ideas in a real world sense (we can't always patch the C compiler!). > POSIX compatibility should apply to both versions. I also think POSIX compliance is very important for all versions. >> The second is the 'upmarket' Minix that everyone seems to think is so >> important, why? Most people who got into Minix for reasons other than formal >> education just wanted to 'hack around'. >> If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO, >> etc offerings. They produce different BINARIES for each processor ... > > Not only did I buy Minix to play with, but also to have a version >of Unix with almost full source code, and to be a part of comp.os.minix, >where each of us can add to Minix's source code pool, and also help >with design ideas, bug reports etc. This is difficult (nay, impossible) >with real Unix. I learn an awful lot by hacking, and I don't have time to take OS classes, so Minix is my vehicle for learning the guts of a Unix-like OS. Having all the sources is both a boon and a bane. I'm sure you understand how it is a boon, and the bane is the much stronger temptation to spend lots of time trying to "just get in there and fix it" rather than finding a work-around, or being happy with the current limitations. The makes Minix a tremendous time-sink for me :-) > At the present point in time, Minix only vaguely resembles current >flavours of Unix, and I would really like to see it become as compatible >with both the ATT and Berkely flavours of Unix. This has already started >with sources such as termcap(3), and the memcpy,bcopy variants. Both >flavours of Unix overlap in many areas, and also have extensions which exists >in only one flavour. If Minix could be a fusion of both flavours, and >keep compatibility with them AND POSIX ( & SVID ?), then we would have >an O/S which would be the best of both worlds AND with source. There are many thing in more modern *nixes that are worth looking at as example of what will and won't work well as a future direction. I think it's foolish to freeze Minix at the "let's make it look like V7" stage. >> What is >> needed is some form of arbitration committee to decide what goes in the >> upmarket version. This should not just rest on ast's shoulders, I prefer >> he gets more time to write his great books! :-) > > Yes! Andy, 'though, being the founder of Minix, should have the >final say on the future of Minix. But a committee of some sorts would >take a lot of the load from him. I don't know about this design-by-comittee stuff. The sources were made widely available, if I understand correctly, to make Minix ACCESSABLE and LEARNABLE to people who aren't going to spend thousands for a source license. I'd like Andy to comment on how he feels about a net-supported upgrade path that may deviate from the "teaching OS" baseline. I don't think an offical non-Andy standards body is really needed, though. If the net-users collectively like a change, it will continue to be carried along in future mod-packages, etc. The biggest problem I see is how to make a certain set of mods into the next "official" version so that new users can buy the complete package from PH. I don't know the answers to these distribution problems. I'm just planning to continue working on changes that I think are useful, and hope they will be used and made available to other, somehow. >BTW, speaking of Minix design, what about job control and the extra >Berkely signals for Minix. This will allow shells etc, to have better >control over child processes, and won't be incompatible with the >Version 7 & SysV signals - well, perhaps a few! Any ideas, comments? Ah.. Lots of ideas. I'm working with the ST version of Minix, but some of what I'm working on will hopefully port back to the PC verison. Some will definately not, but that's mostly because I will be working in the machine dependent code quite heavily. In working on getting uucp going, (yes, that's still in progress) I've had tremendous trouble with the rs232 driver, so I've been looking into it and have decided to rewrite a good portion of it, both to improve the reliablility of the interrupt routine (which had a few bugs) and to improve overall performance by letting the clock tick trigger the rs232 task when there is data rather than processing on every rs232 buffer interrupt. Also, I'm moving away from the sgtty structure toward termio, probably with the Sun extension for window sizing (make 25/50 line mode much easier). Also in the queue, not directly from me, but from someone I'm working with, is support for PTY's. He says this should be a pretty small change, and can be very useful. I've also taken Andy's suggestion on p.184 and implemented direct data transfer between user processes and the FS/MM. This breaks the modularity ideal, but results in a good performance increase (20-30%). My code is conditionally compiled so the "clean" method is still available. In addition, since this is ST code, a further conditional mod may be the use of the blitter chip, if you have one, to assist in the copying. Further down the road I'm looking into implementation of STREAMS and the X window system. These upgrades will require significant mods to the core of the kernel, maybe even restructuring the task switching and message passing code. I hope that my work will be appreciated by the user community and will find it's way into the "official" version, but regardless, I'm going to use the changes, and I expect there are other out there who will also. -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104-3527 ...bungia!midgard.mn.org!syntel!dal United States of America "I may be competitive, but I'm never ruthless"
allbery@ncoast.ORG (Brandon S. Allbery) (06/11/89)
As quoted from <798@gara.une.oz> by wtoomey@gara.une.oz (Warren Toomey): +--------------- | Therefore, I propose that Minix be broken into two parts. One, a simple | static version of Minix, such as 1.3, to be used to teach about | operating systems, and based on the XT or ST. The other, a continually | evolving system, to keep everybody else happy. This should be ported to | many machines, like the ST, '286 & '386 etc, and hopefully should mean | that all the machine dependencies will reside in only a few files in the | kernel/mm/fs/etc. +--------------- If you're so interested in working on a PDist "real Unix", maybe you should send a note to rms@prep.ai.mit.edu. Dr. Tanenbaum has made it clear that Minix is intended for educational use only. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser