ham@warwick.UUCP (Hot Air Machine Project) (06/17/87)
Hello again, this is a little update about the 32016 port of Minix, plus
a bug fix and a request.
The kernel seems to be working fine apart from the tty driver (what else!)
which lacks a few useful v7 features like TANDEM mode etc; I will be doing
a proper rewrite of it soon. John has modified the PROMs on our 32016 boards
to boot off the floppy, so we now have Minix loading in the traditional way;
kernel grabbed off floppy, and then root diskette loaded into RAM disk -- a
nice twist is that with 800k floppies, we decided to partition the floppy
disk, so /dev/fd0a (from which the RAM disk is loaded) starts 200k into the
disk, thus we only need one disk to boot from.
The latest version of init looks at /etc/ttys and forks a shell for each
terminal (each having a different process group of course!) et voila! Multi
user Minix! (Login works; we just can't be bothered to type passwords all
the time :-)
We want to start porting the utilities across now (we have the essentials),
but we have run into problems transferring files:
Unfortunately the tty I/O is mind-bogglingly slow, partly because it is over
RS-232 lines. It can keep up (just) with a couple of hackers using
microGnuEmacs, but can't keep up with touch-typists; it just misses
interrupts.... In view of this, has anyone got a file transfer package
such as kermit running on Minix yet? I have tried a teeny-weeny version,
but the connect mode kept losing characters as the VAX I was talking
to sent them too fast (no, this wasn't a baud rate mismatch). If you have
done anything like this, how did you manage, and how fast does it go?
....And the bugfix. stty.c performs its ioctl()s on file descriptor 0 (stdin)
this means that to change the settings on terminals other than the one you
are using, you have to type e.g: stty -echo < /dev/tty1
which is rather counter-intuitive, not to mention different to UNIX. The
solution is to replace all occurences of "ioctl(0," by "ioctl(1," in stty.c --
I think there are four of them.
Now for a couple of messages....
reza at kcl??
I tried to mail you, but kept getting bounced. The first part
was answered (more appropriately for PCs) by Andy Valencia, and I am afraid
we know very little about PC Minix, and nothing at all about PCs, so we can't
help you with the Hard disk... could you send us a nice, simple address, maybe
relative to ukc or mcvax?
John Gilmore @ingres
You should have got some mail from us, but if not, YES PLEASE, we would love
a copy, please mail us again with details of how to get one... do you know
of any PD or cheap 32016 assembler/linkers?
Thanks for your time,
Tim Bissell
donald@warwick.UUCP or {..seismo!}mcvax!ukc!warwick!donaldjgh@gec-mi-at.co.uk (Jeremy Harris) (06/19/87)
In article <549@ubu.warwick.UUCP> ham@warwick.UUCP (Hot Air Machine Project) writes: >....And the bugfix. stty.c performs its ioctl()s on file descriptor 0 (stdin) >this means that to change the settings on terminals other than the one you >are using, you have to type e.g: stty -echo < /dev/tty1 >which is rather counter-intuitive, not to mention different to UNIX. The > >Tim Bissell >donald@warwick.UUCP or {..seismo!}mcvax!ukc!warwick!donald From memory, this is what V7 stty does. Where's it gointa put its output, eh? Stdout. What is there left to ioctl on? Choice of stdin or stderr. Stdin wins. Yes, one's mind glitched when first meeting it, but if you're stty-ing someone else's terminal then you're probably heading for 'local guru' status anyway :-) I didn't mind it. The horror started (for me, I think I remember) with Sys III. Some bright spark had decided that they didn't like the above behavior, and adjusted stty to tweak it's stdout (just like you want) *and put its output on stderr*. Now, I expect error messages to come to stderr, and normal operating output to come to stdout. I hated it. Disclaimer: It was some time ago, and they weren't AT&T systems. Sorry if I just annoyed anybody. (Not my company's opinions) Jeremy Harris jgh@gec-mi-at.co.uk ...!mcvax!ukc!hrc63!miduet!jgh
rolf@warwick.UUCP (Rolf Howarth) (06/30/87)
In article <602@gec-mi-at.co.uk> jgh@gec-mi-at.co.uk (Jeremy Harris) writes: >From memory, this is what V7 stty does. Where's it gointa put its output, >eh? Stdout. What is there left to ioctl on? Choice of stdin or stderr. >Stdin wins. Yes, one's mind glitched when first meeting it, ... >The horror started (for me, I think I remember) with Sys III. Some bright >spark had decided that they didn't like the above behavior, and adjusted >stty to tweak it's stdout (just like you want) *and put its output on stderr*. >Now, I expect error messages to come to stderr, and normal operating output >to come to stdout. I hated it. >Disclaimer: It was some time ago, and they weren't AT&T systems. Sorry if I > just annoyed anybody. Not AT&T systems maybe, but 4.x uses stdout to determine the device. (Sys V uses stdin, so I guess you're right and V7 did as well). Personally stdout makes more sense to me, in that you may well want to pipe stuff into the stty command. What does V7 stty do if its stdin is a file rather than a device? Also, there's not much wrong with using stderr for output if you regard it as being the `diagnostic' output channel rather than strictly for `errors' only. Matter of taste and what you're used to I suppose. (Remember Unix != Unix) If you will let people fiddle with their operating system ... -- Rolf Dept. of Computer Science, Tel: +44 203 523523 ext 2485 Warwick University, JANET: rolf@uk.ac.warwick.flame Coventry, CV4 7AL. UUCP: {seismo,mcvax}!ukc!warwick!rolf England.