m937290@usna.navy.mil (Midn. Norman R. Solis (937290) <m937290@usna.navy.mil>) (01/31/91)
Just for the sake of asking the question: What kind of features would you like to see added to MINIX? -- | Richard Solis m937290@n1.usna.navy.mil Class of 1993 | | USNA 33rd Company m937290@csvax2.scs.usna.navy.mil | | Annapolis, MD 21412 WA3YIJ | | (301) 267-5001 GO NAVY, BEAT ARMY!!! Standard disclaimers apply! |
ast@cs.vu.nl (Andy Tanenbaum) (02/02/91)
In article <137@usna.NAVY.MIL> m937290@usna.navy.mil (Midn. Norman R. Solis (937290) <m937290@usna.navy.mil>) writes: >What kind of features would you like to see added to MINIX? None. Andy Tanenbaum
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (02/02/91)
>Just for the sake of asking the question: > >What kind of features would you like to see added to MINIX? > 1. Full ANSIfication and POSIXification of the system 2. Implement all 3 dates in the filesystem 3. Multi-threaded filesystem 4. Virtual memory on machines that will handle it. 5. TCP/IP with Ethernet and SLIP interfaces (done by someone?) 6. Graphics and windows (not necessarily X windows) 7. Better floating point support 8. Better disk drivers (I'm working on this...) 9. Symbolic links? (has been done, but not standard) 10. Support for larger buffer cache on 80386 machines. (also done?) 11. Standard and robust UUCP software. (Coherent has this why not Minix. Yes, I know it is out there.) 12. Mouse support (helps with windows) 13. DOS emulation using virtual 8086 on 386 (okay this is asking a little much) 14. Ports of lots of PD Unix code. (Some stuff is only feasible after the system is improved. I really want to port the SC spreadsheet, but first I want to take a look at the state of the floating point support.) 15. True DES encryption of passwords. (a nit) 16. Better scheduling algorithms. 17. A standard debugger on Intel machines. (Boy this would be nice) 18. The ability to profile executables. 19. Complete VT-100 support in the console driver and a good terminal program with integrated dialing and file transfer. 20. Long filenames. 21. POSIX Job Control (isn't this optional for POSIX?) This is a good start. Let me know when you are finished. :-) Bill Bogstad
rt2@cunixb.cc.columbia.edu (Rens Troost) (02/04/91)
I love minix, but boy would a debugger be nice. I'm currently doing development on sun-OS, moving the results to minix, and sweating the differences. ast has been vocal about keeping the thing simple and clean, but the lack of an intel debugger is just intolerable. -Rens
peter@stca77.stc.oz (Peter Jeremy) (02/04/91)
In article <43516@nigel.ee.udel.edu> wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes: >15. True DES encryption of passwords. (a nit) This is not a good idea. True Unix crypt(3) is not quite DES (hence you can't use fast hardware DES chips to crack passwords). And there is no real need for the passwords to use the standard Unix crypt() anyway. If you are really keen on security, why not use snefru as posted to comp.sources.unix last March (v21i019 .. v21i022) [but note that the 2-iteration version has been broken]. >19. Complete VT-100 support in the console driver and a good terminal >program with integrated dialing and file transfer. Nah, who wants VT100. Make it full ANSI X3.64 (from memory) support. And while you're at it, add support for X and PHIGS and ... :-) :-) -- Peter Jeremy (VK2PJ) peter@stca77.stc.oz.AU Alcatel STC Australia ...!uunet!stca77.stc.oz!peter 240 Wyndham St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015
PPH93%DMSWWU1A.BITNET@cunyvm.cuny.edu (Thomas Heller) (02/04/91)
In article <8912@star.cs.vu.nl>, you say: > >In article <137@usna.NAVY.MIL> m937290@usna.navy.mil (Midn. Norman R. Solis > (937290) <m937290@usna.navy.mil>) writes: > >>What kind of features would you like to see added to MINIX? > >None. > >Andy Tanenbaum What about those requested by POSIX ??? Thomas Heller
vladimir@Eng.Sun.COM (Vladimir G. Ivanovic) (02/05/91)
If the raison d'etre of MINIX is pedagogical, shouldn't there at least be a version (MAXIX?) which supports >3. Multi-threaded filesystem >4. Virtual memory on machines that will handle it. >9. Symbolic links. >16. Better scheduling algorithms. >18. The ability to profile executables. >20. Long filenames. >21. POSIX Job Control -- Vladimir -- ============================================================================== Vladimir G. Ivanovic Sun Microsystems, Inc (415) 336-2315 2550 Garcia Ave., MTV12-33 vladimir@Sun.COM Mountain View, CA 94043-1100 Disclaimer: I speak for myself. ==============================================================================
leo@krabat.marco.de (Matthias Pfaller) (02/05/91)
In article <8930@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > >16. Better scheduling algorithms. > It is a single user machine. Round robin should be good enough for that. You should know that this simply is not true; On page 80 of "Operating systems: Design and Implementation" you mention some criteria what a good scheduler should try to achive. For a single user machine I think that at least point 1 and 3 are interesting. 1. Fairness: make sure each process gets its fair shar of the CPU This is NOT true for the current scheduling algorithm of minix. Compute-bound processes have a higher preference then IO-bound processes. This is because if a IO-bound process gives up the CPU to make a call to the fs. Now the CPU-bound process consumes his timeslice complete, even if the systemcall of the IO-bound process has allready finished; So the CPU-bound process gets 99% of the CPU-Time. This makes point 3 impossible: 3. Response time: minimize response time for interactive users. One of the features of minix is Multitasking/programing; So if I compile in the background, I wish to have a acceptable responsetime in the foreground. I have read all the articles about multithreading fs... and I thought: Ok, the bad response time is because all these fs-calls can't be done in parallel. But then I build Kai-Uwe's priority-driven scheduler into my minix 1.5-kernel. From this point of time I never even wasted ONE thought for a multi-threading fs; The responsetime is now acceptable; I can compile in the Background and let an editor running in the foreground; I almost allways get immediate response to key-presses. I think a better scheduling algorithm would be a real winn for minix and 1. It's a real small change to the kernel (only a few lines) 2. You would hear the 'why is fs not multi-threaded ...' much less Matthias Pfaller (leo @ marco.de)
lucio@proxima.UUCP (Lucio de Re) (02/05/91)
In article <1991Feb4.085038.23400@qut.edu.au> lunnon@qut.edu.au writes: >In article <8912@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >> In article <137@usna.NAVY.MIL> m937290@usna.navy.mil (Midn. Norman R. Solis (937290) <m937290@usna.navy.mil>) writes: >> >>>What kind of features would you like to see added to MINIX? >> >> None. > > >Aw, come on Andy, a multi-threaded file system at least :- > BOB > R.Lunnon@qut.edu.au I share Andy's sentiments to a T. I believe Minix is growing beyond manageable size, and there seems to be no way of checking its growth or modularising it. More's the pity. Personally, what I would like to see is a very tight kernel, call it what you wish - my choice would be to name it after Dijkstra - to enable networked PCs running varied operating systems to share their filesystems. Utopia? I'm working on the concepts, but at a purely conceptual level; heavens knows what will come of it! -- Lucio de Re. Internet: lucio%proxima@ddsw1.mcs.com usenet: ...!uunet!ddsw1!proxima!lucio
agm@stl.stc.co.uk (Andrew G. Minter) (02/05/91)
In the referenced article ast@cs.vu.nl (Andy Tanenbaum) writes: >a case in point is the changes for TCP/IP support that are >1.6.11 or Bruce's 32-bit stuff in 1.5). > >Andy Tanenbaum 1.6.11???? Pretty please, beg, beg, beg, post it! Andrew
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (02/05/91)
Andy writes: >>3. Multi-threaded filesystem > Never. OK, it would be horribly complex. Why not using message buffering then, as we did back in 1.2 ???? It worked great then! >>6. Graphics and windows (not necessarily X windows) > As long as it doesn't need much kernel support and runs in user-space, > I have no objection. I will post a long message about this later. >>7. Better floating point support > V2.0 will have full ANSI/IEEE floating point. Vapourware. >>9. Symbolic links? (has been done, but not standard) > No. It is not in P1003.1 But it WILL be present, wanna bet? I just finished a clean implementation. >>10. Support for larger buffer cache on 80386 machines. (also done?) > No. 64K + 64K still reigns until all the 8088 and 80286 machines vanish > into the junk heap. Bull. If MS-DOS can do it, we can do it as well. On '286 machine, only the 64+64 limit is a limit. It can be a (relatively straighforward) change to MM. Since ACK does not understand about multiple segments, one has to use an external compiler (like tcc -mm) to generate binaries for this. We can give these news memory models new magic numbers, to MM can see what it gets... >>11. Standard and robust UUCP software. (Coherent has this why not >> Minix. Yes, I know it is out there.) > As long as it doesn't affect the OS, I'm neutral. I got the hint. It won't be long now... >>12. Mouse support (helps with windows) > Aren't mice just RS232 devices? Yes, and I _did_ write a driver for the Microsoft serial mouse/ Genius GM-6000. Works OK. TOgether with my Hercules Bitmap driver, it is even useful. See below. >>13. DOS emulation using virtual 8086 on 386 (okay this is asking a little >> much) > Ha. ha. Even more Haha, ik lach me dood (== Dutch). >>16. Better scheduling algorithms. > It is a single user machine. Round robin should be good enough for that. Bull, bull, bull. You know what is happening in _my_ room. I am sure I am not the _only_ person alive using MINIX for multi-user environments.... >>17. A standard debugger on Intel machines. (Boy this would be nice) > I actually agree. What about "mdb" for the iNTEL? It exists.... >>18. The ability to profile executables. > There is something to be said for that, but it probably requires a bunch > of kernel changes :-( Bruce Evans did that a long time ago. It wasn't perfect then, but I think it was a start... >>19. Complete VT-100 support in the console driver and a good terminal >>program with integrated dialing and file transfer. > Use kermit. Bull. Did you ever try to fetch 600Kbyte with Kermit, on a bad line? I do this often, and then XCOMM, "cu" (part of the new UUCP) or Pcomm is the _only_ acceptable thing, since they can use Zmodem. >>20. Long filenames. > Never. Hurray. Usually, 14 chars is long enough. However.... >>21. POSIX Job Control (isn't this optional for POSIX?) > Not in 1991 > Not in 1992 > Not in 1993 > Not in 1994 > Not in 1995 ? Overflow error in 1995. You made your point... > has for everything else. It is just a horror. True. REAL job control (i.e. not a quick hack) is a horror. It changes almost _every_ part of MM, FS _and_ Kernel. A no-no. Now, for the "see below" part. The current situation is as follows: - we have ONE serial driver (i.e. RS-232C). - we have THREE high-level protocols for it: 1. TTY 2. MOUSE 3. SLIP (yes!) I have a working mouse driver, but that required hacking in the kernel. It uses the standard RS232-driver to get its bytes, up to a complete packet. Then it looks at the packet data, updates its counters, and that's it. The user can always do a read() on /dev/mouse to retrieve the driver's current state. Easy! However, it is EITHER "tty" OR "mouse"..... :-( Therefore, I hereby want to ask You All about whether to implement the ioctl(fd, TIOCLDISC, ...) system call. This would enable us to use the SAME RS-232 driver for more than one thing, without the need for recompiling the kernel. I am willing to implement it. Fred.
windy@andrej.informatik.rwth-aachen.de (Andrew John Stuart Miller) (02/05/91)
EOAHMAD%NTIVAX.BITNET@cunyvm.cuny.edu writes: >Am I alone? Are those people working on transputer and SPARC microprocessors >still insist on having virtual memory? Virtual memory is good provided we >have a standard chip to handle memory management, like serial and parallel >ports. Judging fromm Disk Controller designs, there will never be a standard >memory manager chipsets. It will always be constantly upgraded. I work with transputers (Helios) Sparcs (unix) Sun-3s (unix), PCs (Minxi) and STs (OS9-68000) It depends how you use virtual memory. For real time applications, anything that requires that data or programs be read from disk is unacceptable. OS9 takes this approach - programs are loaded and are not swapped out. to overcome the possible "Out of memory" problems, any program in main store exists as a module, and the text can be shared by many calls to that program. Some (complex and therefore not likely to be included in an offical minix release) software ensures that the store available is used as efficiently as possible. There are many problems which can only be solved without paging or swapping delays, and many other problems do not need to suffer these delays unnecessarily. For a transputer in a large network, the last thing I want is virtual memory to cause swapping or paging traffic through the network, or the cost of one disk per transputer, which would otherwise be needed. This is already a problem on all the sun-3 networks I have used, paging takes place via ethernet, rather than direct to a hard disk, and the delays are very noticable. Helios also tries to save memory in a similar way to OS9. There are many hardware and software solutions to memory management, just as for hard or floppy disk controlers etc. This is because different systems must meet different requirements. Andy Had one major requirement when mm and fs where implemented - simplicty.This leaves it up to the individual programmer to add his own things to a system when neded. Do not ask people to compilcate things unless completely needed..... Andrew Miller -- -------------------------------------------------------------------------------- email: windy@strange.informatik.rwth-aachen.de snail: Ruetscherstr 165 D-5100 Aachen voice: 0049 (0)241 894-355
klehr@sun.soe.clarkson.edu (Thomas J. Klehr) (02/06/91)
I'd be interested in seeing you mouse driver. Could you send me the source/patches for it. Thanks. Tom (klehr@sun.soe.clarkson.edu)
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (02/06/91)
Well, it seems that my response to the "Most requested features..." posting has generated a small firestorm on the list. First of all, I want to say that I understand AST's wishes to keep Minix a manageable size so that it can be used for teaching purposes. At the same time, many "hackers" have latched onto Minix as the only widely known operating system for which source code is available and inexpensive. They want to turn Minix into a complete operating system with many of the capabilities of Minix's commercial brethren. In the past, the result of these two conflicting goals has been a succession of Minix releases that slowly improve the system while maintaining the ability to run it on small PCs. My impression is that the next generally available release of Minix will probably be the last one for which that will be possible to keep these two goals in sync. In my previous posting, I included a grab bag of "features" which might be considered useful by different individuals. Some of them are obviously unlikely to occur. Some of them I don't even really want. (DOS emulation in particular. A :-) would probably have been of use there.) Some of them, I have heard mention of in the past on this mailing list, but for whatever reason they don't seem to have had wide availability. Perhaps it is time (as one poster suggested) for a MAXMINIX. Some kind of forum where discussion and organization of efforts which are not expected to EVER become part of the standard release might be useful. Hopefully, both groups would continue to communicate with each other and share ideas. It might not even be necessary to set up a separate mailing list as long as the discussions of MAXMINIX were clearly indicated. To start this process it would help to know what capabilities are planned for the next standard release. I understand that it will depend on the time that various individuals including AST can spend in putting it together. Some idea of the goals would help those of us who would like to make a contribution to Minix, but are not on the "inside", could find ways in which we could contribute. I was somewhat disheartened to discover after posting my request for volunteers to look at a new AT_WINI driver to discover that others had been working on it as well and at least on the machines that I have access, my performance numbers are no better. I was disheartened not because someone had gotten better results, but because I could have been spending more of my limited "hacking" time on other Minix goals. Maybe a "todo" list with people interested in particular areas would work. Well, those are some of my thoughts on Minix. I have mentioned some of this to others when discussing the AT_WINI driver. I look forward to others suggestions and comments on whether any of the above is feasible or even worthwhile. Thanks, Bill Bogstad P.S. There may be some who say that I should wait for the GNU project or free BSD code if I want a "large" OS with source code. That is certainly an option and if it is deemed to be the best way to deal with the situation then I will have to pursue my interests in those arenas.
hwr@pilhuhn.ka.sub.org (Heiko W.Rupp) (02/06/91)
Organization: Not an Organization In article <8912@star.cs.vu.nl>, Andy Tanenbaum writes: >In article <137@usna.NAVY.MIL> m937290@usna.navy.mil (Midn. Norman R. Solis (937290) <m937290@usna.navy.mil>) writes: > >>What kind of features would you like to see added to MINIX? >None. What I'd like to have for AMIGA-Minix : -Harddisksupport (to be added) -A bug free version from P-H -Support of 680x0 with x!=0 (to be added) -Heiko -- Heiko W.Rupp, Gerwigstr.5, D-7500 Karlsruhe 1 | hwr@pilhuhn.ka.sub.org Tel: +49 7021 693642 (voice only) | uk85@dkauni2.bitnet make love make: don't know how to make love
Peter_Van_Epp@cc.sfu.ca (02/06/91)
>From: wjb%cogsci.COG.JHU.EDU@VM1.NODAK.EDU > >????Thanks, >????Bill Bogstad > >P.S. There may be some who say that I should wait for the GNU project or >free BSD code if I want a "large" OS with source code. That is certainly an >option and if it is deemed to be the best way to deal with the situation >then I will have to pursue my interests in those arenas. Assuming that the free BSD code refers to the 386 port being documented in Dr Dobbs, there is bad news from the BSD BOF at the last Usenix in Dallas, the BSD folks said the article is in error, there is still ATT code in the BSD kernel and they don't have an estimate of when it will be gone. GNU announced (also at a BOF) that they have come to an agreement with CMU on a Mach licence and they would be starting work on a GNU kernel but again no estimate of when it would be availible (but I got the impression they didn't think it would be soon).
kevin@nuchat.sccsi.com (Kevin Brown) (02/06/91)
BTW, to remain on topic, I think we need #! recognition in the kernel. This seems to be one big difference between Minix and other flavors of Unix (don't know if V7 had it or not, though). In article <743@krabat.marco.de> leo@krabat.marco.de (Matthias Pfaller) writes: >In article <8930@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >> >16. Better scheduling algorithms. >> It is a single user machine. Round robin should be good enough for that. If it were a single-tasking machine, I would agree. ;-) >You should know that this simply is not true; >On page 80 of "Operating systems: Design and Implementation" you mention some >criteria what a good scheduler should try to achive. For a single user >machine I think that at least point 1 and 3 are interesting. >1. Fairness: make sure each process gets its fair shar of the CPU > This is NOT true for the current scheduling algorithm of minix. > Compute-bound processes have a higher preference then IO-bound > processes. This is because if a IO-bound process gives up the CPU > to make a call to the fs. Now the CPU-bound process consumes his > timeslice complete, even if the systemcall of the IO-bound process > has allready finished; So the CPU-bound process gets 99% of the > CPU-Time. > >This makes point 3 impossible: >3. Response time: minimize response time for interactive users. Yup. The question is at what cost (in terms of simplicity) do you get a better scheduling algorithm? If the changes are only a few lines, then I agree that they should be made part of the standard distribution. Let's face it: Minix isn't just about teaching OS, it's also about teaching GOOD OS techniques. I think a good scheduler is part of that, and thus think it should be part of the Minix distribution (IF it's simple, of course :-). >One of the features of minix is Multitasking/programing; So if I compile >in the background, I wish to have a acceptable responsetime in the foreground. >I have read all the articles about multithreading fs... and I thought: >Ok, the bad response time is because all these fs-calls can't be done in >parallel. But then I build Kai-Uwe's priority-driven scheduler into my >minix 1.5-kernel. From this point of time I never even wasted ONE thought for >a multi-threading fs; The responsetime is now acceptable; I can compile >in the Background and let an editor running in the foreground; I almost allways >get immediate response to key-presses. Please, Please, PLEASE, PUHLEEEZE post the diffs relative to vintage 1.5.10 for this! I know I would find it useful, and I suspect MANY others would find it useful as well. I eventually want to get UUCP, mail, and news up on my machine, and something like this will make a big difference. Unless I'm being brain dead here. Is the scheduler you refer to something that has actually been posted here already? If so, could you email it to me (or, better yet, do the context diffs anyway, unless you made no changes to anything when you did the installation, i.e. no bug fixes and the like). >I think a better scheduling algorithm would be a real winn for minix and >1. It's a real small change to the kernel (only a few lines) It is? Cool. I'm looking forward to this. :-) >2. You would hear the 'why is fs not multi-threaded ...' much less How well does the scheduling algorithm deal with multiple I/O-bound processes going on at the same time, e.g. two compiles? How well does it deal with multiple users? > Matthias Pfaller (leo @ marco.de) -- Kevin Brown Disclaimer: huh? nuchat!kevin@uunet.uu.net or csci31f7@cl.uh.edu Minix -- the Unix[tm] of the 90's. System V -- the Multics of the 90's. :-)
ast@cs.vu.nl (Andy Tanenbaum) (02/06/91)
In article <3999@stl.stc.co.uk> "Andrew G. Minter" <agm@stl.stc.co.uk> writes: >1.6.11???? Pretty please, beg, beg, beg, post it! It is not ready. To keep up on these internal versions, join the beta group maintained by Glen Overby. Andy Tanenbaum (ast@cs.vu.nl)
ghelmer@dsuvax.uucp (Guy Helmer) (02/06/91)
In <910205260@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >Andy writes: >>>3. Multi-threaded filesystem >> Never. >OK, it would be horribly complex. Why not using message buffering then, >as we did back in 1.2 ???? It worked great then! I never saw much about this message buffering --- where did it go? >>>10. Support for larger buffer cache on 80386 machines. (also done?) > If MS-DOS can do it, we can do it as well. On '286 machine, >only the 64+64 limit is a limit. If you're going to break the 128K barrier, PLEASE ADD SWAPPING, TOO! 640K or 1Mb (which is what the great majority of users of PC-Minix have) is not enough memory to let a system run uninhibited. Too many things either die quietly or can't be done on a system will several processes running. Swapping would be a big win for the occasional times when memory needs to be overcommitted, and overcommit will occur more frequently if processes become larger. (I bet the noticeable overhead from a swapper would be greatly reduced by a quality scheduling algorithm) >>>16. Better scheduling algorithms. >> It is a single user machine. Round robin should be good enough for that. Simple round robin is ok until you start running more than one process :-) Even real UNIX V7 has a more complex scheduler. >>>20. Long filenames. >> Never. >Hurray. Usually, 14 chars is long enough. However.... Long file names as part of an implementation of Joy's Fast File System would be quite awesome, and a wonderful enhancement for MINIX; this doesn't belong in the std distribution, though. Even though the MINIX file system shouldn't become as fragmented as the true UNIX file system, the other performance gains would make MINIX feel quite peppy. >>>21. POSIX Job Control (isn't this optional for POSIX?) (Gag. Barf.) Use virtual terminals if you want to run several things from one real terminal. -- Guy Helmer helmer@sdnet.bitnet, uunet!dsuvax!ghelmer Dakota State University Computing Services ------------------- (605) 256-5315 MidIX -- networks, databases, DOS, UNIX, & MINIX ------------- (605) 256-2788
nicolas@cli52or.edf.fr (02/06/91)
> > In article <8930@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > > >16. Better scheduling algorithms. > > It is a single user machine. Round robin should be good enough for that. > > You should know that this simply is not true; > On page 80 of "Operating systems: Design and Implementation" you mention some > criteria what a good scheduler should try to achive. For a single user > machine I think that at least point 1 and 3 are interesting. > 1. Fairness: make sure each process gets its fair shar of the CPU > This is NOT true for the current scheduling algorithm of minix. > Compute-bound processes have a higher preference then IO-bound > processes. This is because if a IO-bound process gives up the CPU > to make a call to the fs. Now the CPU-bound process consumes his > timeslice complete, even if the systemcall of the IO-bound process > has allready finished; So the CPU-bound process gets 99% of the > CPU-Time. > > This makes point 3 impossible: > 3. Response time: minimize response time for interactive users. > > One of the features of minix is Multitasking/programing; So if I compile > in the background, I wish to have a acceptable responsetime in the foreground. > I have read all the articles about multithreading fs... and I thought: > Ok, the bad response time is because all these fs-calls can't be done in > parallel. But then I build Kai-Uwe's priority-driven scheduler into my > minix 1.5-kernel. From this point of time I never even wasted ONE thought for > a multi-threading fs; The responsetime is now acceptable; I can compile > in the Background and let an editor running in the foreground; I almost allways > get immediate response to key-presses. > > I think a better scheduling algorithm would be a real winn for minix and > 1. It's a real small change to the kernel (only a few lines) > 2. You would hear the 'why is fs not multi-threaded ...' much less > > Matthias Pfaller (leo @ marco.de) > Perhaps could you post your diffs, and you will get some reactions ... I think it could be interesting for some of us
ast@cs.vu.nl (Andy Tanenbaum) (02/07/91)
In article <43780@nigel.ee.udel.edu> wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes: > > To start this process it would help to know what capabilities are >planned for the next standard release. I understand that it will depend on >the time that various individuals including AST can spend in putting it >together. Some idea of the goals would help those of us who would like to >make a contribution to Minix, but are not on the "inside", could find ways in >which we could contribute. The major goal for 2.0 is ANSI and POSIX-ification. Everything else is rather secondary. If you want to help, there are two possibilities. 1. Join the beta-test group, to help with testing periodically. 2. POSIXize one of more of the utility programs. The list of who has has promised to do what, to avoid duplication, is below (in tbl format). If there is a program that is not already signed up for that you would like to POSIXize, please let me know. Andy Tanenbaum (ast@cs.vu.nl) .TS center allbox; l l l c. \fBWho What Status Integrated?\fR awk [-F expr] program [argument ...] Phil basename string [suffix] Done Yes Phil bc [-l] [file ...] Alan cat [-c] [-u] [file ...] Thomas cd [dir] Vincent chgrp [-R] group file ... Vincent chmod [-R] mode file ... Vincent chown [-R] owner file ... Vincent cksum [file ...] (easy one--the full source code is provided!) Ed cmp [-l | -s] file1 file2 comm [-123] file1 file2 command [argument ...] Vincent cp [-f | -i] [-pR] source target Thomas cut -c list [file ...] or cut -f list [-d string] [-s] [file] Vincent date [-u] [+format] Norbert dd [operand ...] Thomas diff [-c | -e | -C n] [-br] file1 file2 Fred dirname string Eric echo [string ...] ed [-p string[ ] [-] [file] Fred env [-] [-i] [name=value] ... [utility [arg ...]] Paul expr operand ... Alan false Bert find path ... [operand_expr] Norbert fold [-b] [-s] [-w width] [file ...] Norbert getconf system_var or getconf path_var pathname Fred getopts optstring name [arg ...] Norbert grep [-E | -F] [-cilnsvx] [-f pattern_file | -e pattern] ... Eric head [-c | -l] [-n number] [file ...] Fred id [-g | -u] [-nr] [user] join [options] Eric kill [-signal_name] pid ... or kill -1 Vincent ln [-f | -i] source ... target locale [-a | -l locale] [-ckv] [-f charmap] [name ...] localedef [-f charmap] name Fred logger string ... Fred logname Fred lp [-c] [-d dest] [-n copies] [file ...] Earl ls [-CFRacdilqrstul] [file ...] Fred mailx [-s subject] address ... Vincent mkdir [-p] [-m mode] dir ... Vincent mkfifo [-p] [-m mode] file ... Vincent mv [-f | -i] source target .TE .bp .TS center allbox; l l l c. Eric nohup utility [arg ...] Norbert od [-bcdov] [-e format_string] [-f file] [-n ct] [-s skip] [file ...] Thomas paste [-d list] [-s] file ... Vincent pathchk [-d | -f] [-npqtP] [-m mode] [-x prefix] name ... Lars pax [options] Norbert pr [options] printf fomrat [args ...] Norbert pwd Fred read [-r] var ... Vincent rm [-f | -i] [-Rr] file ... Eric rmdir [-p] dir ... sed [-n] script [file ...] sh [-aefinuvx] [-c string | -s] [argument] Eric sleep time Norbert sort [options] stty [options] Norbert tail [-c | -l] [-f] [-n number] [file] Ed tee [ai] [file ...] Jeroen test expression Eric touch [-acm] [-r ref_file | -t time] file ... Jeroen tr [-c] [-d | -s] string1 string2 Alan true Thomas tty [-s] Eric umask [-o | -s | mask] uname [-amnrsv] Eric uniq [-c | -d | -u] [-f fields] [-s chars] [input_file [output_file]] wait [pid] Jeroen wc [-clw] [file ...] Ed xargs [-n number] [-s size] [-t] [utility argument ...]] Tom sh [options] ar [options] Ronald make [-f makefile] ... [-eiknpqrSst] [macro=name] ... [target] ... strip file ... ACK c89 lex yacc asa fort77 .TE .sp 2 .TS center allbox; css l l l. \fB Names of the people doing the Posixizing\fR \fBWho Name Email address\fR Alan Alan Clegg abc@matrix.com Bert Bert Laverman laverman@cs.rug.nl Earl Earl Chew cechew%bruce.cs.monash.oz.au@uunet.uu.net Ed Ed Oskiewicz eo@ansa.co.uk Eric Eric Boehm boehme@leah.albany.edu Fred Fred van Kempen waltje@minixug.hobby.nl Jeroen Jeroen van der Pluym jeroen@minixug.hobby.nl Lars Lars Fredriksen fredriks@ihlpm.att.com Norbert Norbert Schlenker nfs@notecnirp.princeton.edu Ronald Ronald Lamprecht V61@dhdurz1.bitnet Paul Paul Allen pallen@atc.boeing.com Phil Phil Nelson phil@unicorn.wwu.edu Thomas Thomas Brupbacher tobr@mw.lpc.ethz.ch Tom Tom Torrance tomqnx!qnx@csi2.csi.uofo.edu Vincent Vincent Archer archer%segin4.segin.fr@prime.com .TE
hp@vmars.tuwien.ac.at (Peter Holzer) (02/10/91)
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >>>12. Mouse support (helps with windows) >> Aren't mice just RS232 devices? >Yes, and I _did_ write a driver for the Microsoft serial mouse/ >Genius GM-6000. Works OK. TOgether with my Hercules Bitmap driver, >it is even useful. >See below. Sounds interesting. Are you going to post the mouse driver in the near future? >>>17. A standard debugger on Intel machines. (Boy this would be nice) >> I actually agree. >What about "mdb" for the iNTEL? It exists.... Where? I never read about it. Is it on plains? >>>20. Long filenames. >> Never. >Hurray. Usually, 14 chars is long enough. However.... But I want longer filenames. Specifically I am thinking of writing a different FS that should coexist with the normal fs, and it will have longer filenames. That will require lots of changes :-( >I have a working mouse driver, but that required hacking in the >kernel. It uses the standard RS232-driver to get its bytes, up >to a complete packet. Then it looks at the packet data, updates >its counters, and that's it. The user can always do a read() >on /dev/mouse to retrieve the driver's current state. Easy! >However, it is EITHER "tty" OR "mouse"..... :-( >Therefore, I hereby want to ask You All about whether to implement >the ioctl(fd, TIOCLDISC, ...) system call. This would enable us >to use the SAME RS-232 driver for more than one thing, without >the need for recompiling the kernel. As I don't have a terminal, just a mouse, I am rather neutral. However, what does EITHER tty OR mouse mean? Can you have the mouse on port 1 and a terminal at port 2? If this is not possible, some means for alowing this is certainly needed. And while we are at invening new ioctls, how about an ioctl to load different keyboard mappings from the console? Sometime in Autumn I posted a german keyboard driver that used additional arrays for the German mapping. Now if I think of all the different countries in which Minix is sold, that is not the way to go for the standard distribution. Having the keymappings preloaded with an american keyboard and loading the local keyboard in the /etc/rc is much more elegant. Adding somethinglike this to my driver would be trivial. Peter. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
postmaster@ssci.UUCP (Kevin Benton) (02/10/91)
In a message of <Feb 06 16:26>, Andy Tanenbaum (ast@cs.vu.nl ) writes: >1. Join the beta-test group, to help with testing periodically. >2. POSIXize one of more of the utility programs. The list of who has > has promised to do what, to avoid duplication, is below (in tbl format). > If there is a program that is not already signed up for that you would > like to POSIXize, please let me know. Where can we get a POSIX standard listing that we're shooting for? Kevin -- Kevin Benton - SysOp of... Project Thunder (ssci) 1:157/516.0 :-) once in a while... FidoNet 1:157/533.14 you might actually learn UseNet uunet!ssci!kevin to like it!
wssaz@chvax.uucp (Schweizer W.) (02/11/91)
In article <1991Feb3.233633.7986@cunixf.cc.columbia.edu> rt2@cunixb.cc.columbia.edu (Rens Troost) writes: >I love minix, but boy would a debugger be nice. >I'm currently doing development on sun-OS, moving the results to minix, >and sweating the differences. ast has been vocal about keeping the thing >simple and clean, but the lack of an intel debugger is just intolerable. > >-Rens As MINIX is intendes for educational purposes I also think is needs a debugger. I work on ST-MINIX and there IS a debugger (mdb), but only on assembler level. I vote for a SYMBOLIC debugger, which would make life easier for software porters. Also a standard graphical interface would be nice (and user friendli) but let's start by adding graphics at all. (Again on ST there is something - a screen driver - and I modified it to work with multiple consoles {if someone is interessted} but this should be standardised.) Walter
Kenyon_F_Karl@cup.portal.com (02/13/91)
TO: Prentice Hall - Microservice Customer Svc.
EMS: Internet
MBX: books@prenhall.com
CC: Andrew S. Tanenbaum
EMS: Internet
MBX: ast@cs.vu.nl
Subject: Minix 1.5 upgrade
Kenyon F. Karl
P. O. Box 451, N. Andover, MA 01845
508-689-3147 (answering machine)
Internet: 1771813@mcimail.com
X.400: C=US / A=MCI / S=Karl / D.ID=1771813
MCI Mail: 177-1813 -or- Telex: 6501771813
February 11, 1991
Robert J. Coll
College Division
Prentice Hall
Englewood Cliffs, NJ 07632
Sirs:
Please register my copy of minix 1.5 as follows:
Date of Purchase: 02/01/91
Is this your first purchase of MINIX? no
Name: Kenyon F. Karl
Address: P. O. Box 451
City: N. Andover State: MA Zip: 01845
System for which you will be using MINIX: IBM-PC
How did you purchase MINIX: phone
(I wanted to order by e-mail but was told to order by phone instead!)
How did you hear about MINIX: USENET news group 'comp.os.minix'.
Which magazines to I read regularly:
PC Magazine
Computerworld
Comments about the package and the software:
I have just completed a seven week long intensive course presented by
Boston University's Center for Corporate Education in Tyngsboro, MA. The
course covered both Unix Systems Administration and C language programming,
and is intended to produce system programmers / system administrators with
the equivalent of two years of on-the-job experience. Thus, I needed a
modest system that was NOT being used for production purposes, to practice
and extend the skills that I had acquired in class. Money was quite impor-
tant as I am currently out of work.
I was able to install MINIX 1.5 on an otherwise unused IBM-PC clone (8088
CPU) with only moderate difficulty. Even with all of the source code in-
stalled, the system occupies less than 8 meg of a 20 meg hard disk. The
result is a simple UNIX-like system that seems to fit my current needs for
a system adequate for 'self-instructional' purposes quite nicely. Thus, the
$117.60 spent for the upgrade (from MINIX 1.2) replaced a much greater
expenditure for a new 80386-based machine with the extra RAM and a extra
large hard disk drive that would be required for SCO Xenix or UNIX. I am
likewise sure that MINIX was much cheaper than either SCO UNIX or even SCO
Xenix.
The fact that all of the source code is included on the diskettes is a
major plus, as I consider the presence of source code to be much more
important than any promise of 'free technical support'. Thus, I consider
the presence of source code to be 'the best guarantee in the business'. I
am even more impressed because the code was written for 'instructional
purposes' and hence emphasizes simplicity over efficiency.
The presence of source code in the back half of the printed manual strikes
me as an attempt to 'pad' the size of the manual to make it more impres-
sive! Indeed, the listings have to be ignored in favor of the equivalent
files. First the printed versions contain only the kernel code, thus I have
to go to the diskettes for the code for the various utilities. Secondly, it
is quite likely that the printed version may be out of date!
Thus, if it is necessary for 'marketing reasons', I would much rather that
you reprinted appropriate chapters of Tanenbaum's book on operating systems
that is cited on page 4 of the current manual.
I appreciate the presence of the dosread, doswrite, and dosdir utilities in
the IBM-PC edition. This critical piece of MINIX software permits me to
implement a 'sneakernet' scheme between my MS-DOS machine and my separate
MINIX machine. But unless the task is complicated by hardware limitations,
assemply language code or the like, I think that all versions of MINIX
ought to include all of the 'other-OS disk read-write'. Such software would
enable 'sneakernets' between all of the different machines that can ber
used for MINIX.
My current MINIX machine has a hard disk. But I did NOT have that hard disk
when I was experimenting with MINIX 1.2. Thus I suggest that you add a disk
to the IBM-PC package containing MS-DOS software to read/write MINIX format
disks and also to compress/decompress files. This would be a major conven-
ience in the rather common circumstance where much greater resources for
examining and compiling source code are available on a separate MS-DOS
machine.
I would also like to use my Turbo C++ compiler on my MS-DOS machine to
produce raw object code for use with MINIX. Thus, if such is practical, I
need would need some kind of object code conversion program to convert
object produced in the MS-DOS enviroment for use in the MINIX environment.
Similar situations may be encountered in other environments.
The Kermit and the Zmodem software is a very important new addition for
communicating between MINIX and a wide variety of other machines over both
RS232 wire and telephone lines. Although I appreciate the fact that Zmodem
is more sophisticated, Xmodem is more widely available. Thus, I would
suggest that you also include Xmodem software for use when neither Zmodem
or Kermit is available!
Although I am NOT in a position to use the networking software, I do appre-
ciate the ability to study this potentially useful addition to the system.
The absence of UUCP software is a major problem in MINIX because of its
importance in the traditional UNIX environment. Thus finding UUCP or its
equivalent for my system will be my first major 'upgrade' task so I can
link my machine to the 'rest of the world'. Note that because of the size
of my MINIX machine, I suspect that I need a software setup that allows me
to use a 'domain address' in my mail message, but in such a way that the
complete 'routing' of that message would not occur until the message cross-
es the UUCP link(s) to a much larger machine!
UUCP software is now available for the MS-DOS environment as well as sever-
al other personal computer environments. Thus the use of this software
through serial cables (or phone links) would be another way of linking
MINIX to other personal computers. Since this software is available in a
'prtable' source-code format, it may be reasonable to compile and otherw-
iuse modify such software for use with MINIX.
Also, I would also suggest that the shell script /etc/setup_usr be changed
so that the user is NOT required to install all of the source code during
the initial installation. Thus an abbreviated installation would merely
create empty directories for source code. This option should save consider-
able time and disk space for those users that do not need to examine or
modify source code immediately, or are trying to operate in the smallest
possible MINIX partition. Thus, if I read the output of 'du' correctly,
source code occupies 4793 blocks of 7629 total where each block is 1K in
size. Thus an abbreviated installation would require less than 3 meg of
disk space. Note that I will probably undertake this rather trivial task in
the next few days as a practical exercise in 'shell programming'. If suc-
cessful, the results of this exercise will be posted on USENET.
Finally, the MINIX reference manual currently assumes much more understand-
ing of UNIX than I had when I first purchased MINIX 1.2. Thus, in the
absence of a major expansion of the manual, I would suggest that a shopping
list of basic books about UNIX be printed on the outer box (as well as the
MINIX info sheet distributed by the USENET newsgroup) so that a prospective
MINIX purchaser is able to purchase all of the books that they need during
one 'shopping expedition'. The 'Nutshell Handbooks' by O'Reilly & Associ-
ates might be quite useful for this purpose.
Because of it value as a 'wish list' for MINIX, a copy of this correspond-
ence will also be posted to USENET newsgroup 'comp.os.minix'.
bkim@oracle.com (Young Barry Kim) (02/13/91)
>1. Join the beta-test group, to help with testing periodically.
How would we go about doing this?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Barry Kim bkim@wrpyr.oracle.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=PPH93%DMSWWU1A.BITNET@cunyvm.cuny.edu (Thomas Heller) (02/13/91)
In article <910205260@uwalt.nl.mugnet.org>, you say: > >>>6. Graphics and windows (not necessarily X windows) >> As long as it doesn't need much kernel support and runs in user-space, >> I have no objection. >I will post a long message about this later. > >>>12. Mouse support (helps with windows) >> Aren't mice just RS232 devices? >Yes, and I _did_ write a driver for the Microsoft serial mouse/ >Genius GM-6000. Works OK. TOgether with my Hercules Bitmap driver, >it is even useful. > I am currently working on a port of MGR to MINIX. This should really read: porting MINIX to MGR :-). The main work was to write some device drivers, which support: 1. Access to video memory 2. Berkeley style pseudo tty's (pty's) 3. A library function to emulate the SUN-OS select(2) system call. I have it running now (on a 386-PC with Bruce's 386 patches). Concerning mouse: MGR reads directly from the serial port, I only made a link from /dev/tty64 (first serial port with Grodon Irlam's virtual consoles) to /dev/mouse. No need to patch or recompile the kernel. All in all, MGR seems to need NOT very much kernel support, and thus fits very nicely to MINIX. > >Therefore, I hereby want to ask You All about whether to implement >the ioctl(fd, TIOCLDISC, ...) system call. This would enable us >to use the SAME RS-232 driver for more than one thing, without >the need for recompiling the kernel. > Could you describe the TIOCLDISC command, I have no idea what it does? ---------------------------------------------- Thomas Heller, University of Muenster, Germany EARN/BITNET: <PPH93@DMSWWU1A>
jkp@cs.HUT.FI (Jyrki Kuoppala) (02/14/91)
In article <1991Feb11.155205.18570@chvax.uucp>, wssaz@chvax (Schweizer W.) writes: >As MINIX is intendes for educational purposes I also think is needs a >debugger. I work on ST-MINIX and there IS a debugger (mdb), but only >on assembler level. I vote for a SYMBOLIC debugger, which would make >life easier for software porters. Well, I have gdb 3.5 running on pc532 (ns 32532 machine) Minix 1.3 - and no, it isn't very useful because there's no ptrace(2) and I haven't even modified it to read Minix core files yet. But it can read symbols from a.out files well enough, and do disassembly etc. When I modify it reading core files it should be somewhat useful. I use gcc, gas and GNU binutils which use the BSD/GNU dbx format for symbols, so there was really very little to change. The real work is of course implementing the ptrace or similar system call. Has someone implemented ptrace or another system call providing enough functionality for a debugger to use stepping etc. ? This won't help people who use the PH Minix distribution as is, of course (I remember hearing that GNU software will not be with Minix), but for those who can grab the stuff off the net or get software from other distributors than PH can have a debugger. //Jyrki
) (02/14/91)
nicolas@cli52or.edf.fr wrote: >>(good explanation of cpu-bound vs. io-bound procs with the minix scheduler) >> This makes point 3 impossible: >> 3. Response time: minimize response time for interactive users. >> >> One of the features of minix is Multitasking/programing; So if I compile >> in the background, I wish to have a acceptable responsetime in the foreground >> I have read all the articles about multithreading fs... and I thought: >> Ok, the bad response time is because all these fs-calls can't be done in >> parallel. But then I build Kai-Uwe's priority-driven scheduler into my >> minix 1.5-kernel. From this point of time I never even wasted ONE thought for >> a multi-threading fs; The responsetime is now acceptable; I can compile >> in the Background and let an editor running in the foreground; I almost >> allways get immediate response to key-presses. >> > >Perhaps could you post your diffs, and you will get some reactions ... >I think it could be interesting for some of us I *know* i've annonunced this some time ago, but then... 9-) I am actually preparing my sysupd2 upgrade kit, which basically contains an implementation of nice(1,2), profil(2), monitor(3) and a port of the bsd gprof(1). At the moment i am awaiting comments from some "beta testers". Anyway, i think everything is ready next week, so expect a posting at the end of that week. The main point is i don't have a person for a pc port of profil(2). This one is processor dependent in some way, and i can't test my code. Volunteers appreciated 9-). Unfortunately it's a diff kit for my sysupd1 kit i've posted a quite long time ago. However, i've warned you about this when posting sysupd1.tar.Z. If enough persons yell at me i will maybe be convinced and port everything back to native 1.5.10 (but that will last another time slice). To say something about the new scheduling algorithm: Every user process now has a base priority and a current priority, the latter one being recalculated after every descheduling operation for the process. The new current priority is a linear combination of the base priority and the time the process has used up in its last two scheduling quantums. This way I/O-intensive processes get lower priority then a cpu-bound process with the same base priority, hence the response time for the "editing while compiling in background"-example are significantly better for the editor. See the above comments from Matthias.
klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (02/15/91)
wssaz@chvax.uucp (Schweizer W.) writes: >As MINIX is intendes for educational purposes I also think is needs a >debugger. I work on ST-MINIX and there IS a debugger (mdb), but only >on assembler level. I vote for a SYMBOLIC debugger, which would make >life easier for software porters. Of course, a symbolic debugger is nice -- but the current object format does not support symbolic debugging info. (Perhaps you win with GNU C + gdb; but you should have very much ram (2.5+ Meg, or even more ?)) When any runnable compiler (on my 1Meg machine) produces the info, i am willing to rewrite mdb to a symbolic debugger (Or port gdb to minix). (CvW, are you listening :-)) Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (02/15/91)
PPH93%DMSWWU1A.BITNET@cunyvm.cuny.edu (Thomas Heller) writes: >I am currently working on a port of MGR to MINIX. This should really read: >porting MINIX to MGR :-). Good work! (Even better when it also means a 68k port!) >The main work was to write some device drivers, which support: > 1. Access to video memory > 2. Berkeley style pseudo tty's (pty's) > 3. A library function to emulate the SUN-OS select(2) system call. These things are of general interest! Can those goodies be posted soon? Even without MGR i want these! Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (02/19/91)
MINIX-1.5 has a ptrace system call and thus allows breakpoints, single stepping etc. C.v.W.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (02/19/91)
Does POSIX say something about sys/file.h? I have some net software that requires to change all <sys/file.h> to <fcntl.h>, so it would just be handy if there was a sys/file.h, even if it does nothing but to include <fcntl.h> C.v.W.