Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!ncar!gatech!purdue!haven!mimsy!nmrdc1!minixug!uwalt!waltje
From: waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen)
Newsgroups: comp.os.minix
Subject: Re: Most requested features in MINIX...
Message-ID: <910205260@uwalt.nl.mugnet.org>
Date: 5 Feb 91 10:33:40 GMT
References: <8930@star.cs.vu.nl>
Organization: MicroWalt Corporation, for MINIX Software Development
Lines: 112

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.