Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!ncar!tank!shamash!com50!midgard!syntel!dal From: dal@syntel.UUCP (Dale Schumacher) Newsgroups: comp.os.minix Subject: Minix's Direction Summary: These are the features I'm working on. Message-ID: <050989A9892@syntel.UUCP> Date: 9 Jun 89 15:07:54 GMT References: <798@gara.une.oz> <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz> Reply-To: dal@syntel.UUCP (Dale Schumacher) Lines: 111 X-Member-Of: STdNET (ST Developer's Network) 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"