Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!seismo!mcvax!botter!ast
From: a...@botter.UUCP
Newsgroups: comp.os.minix
Subject: Misc. comments and a proposed protocol
Message-ID: <1089@botter.cs.vu.nl>
Date: Fri, 6-Mar-87 17:26:49 EST
Article-I.D.: botter.1089
Posted: Fri Mar 6 17:26:49 1987
Date-Received: Sun, 8-Mar-87 16:29:08 EST
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 110
For those of you who don't subscribe to news.groups, Brian Reid of DEC
collects statistics on USENET. Sites send him reports about groups read
locally, and he has software that prints the TOP 40 and BOTTOM 20 in
order of readership, traffic, etc. These reports are posted monthly.
For February, comp.os.minix was # 36 in readership out of 224 news groups.
There are an estimated 10,000 readers worldwide, which ties it with
soc.singles. Within one month of its inception, MINIX has become as
popular as sex. The drawing of conclusions is left as an exercise for the
reader.
Let me explain the command line limit problem exactly. It was explained in
an earlier posting by someone else, but it wasn't quite right (but it was
close). The logical way to handle the exec system call in MINIX would be
to pass the arg and envp pointers to MM and let it fetch all the args and
strings. This is slow in MINIX, so I wrote exec(2) to build the initial
stack frame inside the calling program, and just send a pointer to it to
MM. MM Then picks it up in one operations. The buffer in which the initial
stack frame is built is 1K. This means that a command like "ls *.c" in a
directory with a few hundred .c files will generate more argument strings
than fit in 1K, and the exec call fails, so the shell says ls: can't execute.
The fix is to make the 1K buffer into a 2K buffer, and fix the size in MM.
This makes all programs using exec 1K larger. I didn't think it was worth
it, but if you want to change it, now you know how.
I haven't finished checking out the new -i flag to asld to support separate
I & D space, but so far it seems to work. I have compiled the whole
operating system with kernel, MM, and FS using -i and it works. I will keep
testing it and when I am done will distribute the new asld binary.
P-H has promised me that that they will be shipping diskettes by March 13.
Sorry it has taken so long to get geared up. You wouldn't believe how
complicated it is. P-H has farmed the manufacturing out. One company does
the diskettes, another does the diskette labels, another does the plastic
box they come in, ...
As large numbers of people get the code, people will find bugs.
I would like to propose a bug protocol to make the reporting and fixing of
bugs less confusing.
1. If you find a bug in the file prog.c, post a message with subject line:
Report of bug in prog.c
2. If you have a fix to some bug (including a bug that you yourself are
reporting), make the subject line:
Fix to bug in prog.c
3. Only one bug report per posting. Many people will keep the bug reports
in mailboxes. By typing h a to msg you get a list of all the subject
lines, so with these conventions it will be easy to find things.
4. Once a bug fix has been reported, it would be nice to have it referreed,
like journal articles. If you feel like installing a fix and testing it,
by all means do so, and then report back with a posting, one bug per
posting, with the subject line like:
Smith's fix to prog.c is ok
or
Smith's fix to prog.c doesn't work
The body of the message can be quite short, telling, for example, on
what machine you tried it, if that is relevant (e.g., for a printer
driver fix, which printer you used). After you have seen half a dozen
people confirm that Smith's fix is indeed correct, don't post any more
confirmations. When testing a fixed program, be sure to test all its
features and options, because the fix may correct one bug but introduce
another one.
6. UNIROT has offered space for an archive. I would suggest that only
fixes refereed in the above way be archived. It would be nice if the
machine could have an archive server that works like Brian Reid's
mod.recipes server. You send it the bug number and it sends you a
message containing the bug report, the fixes, and the referees reports.
Bug 0 should be a list of all the subject lines of the bug reports,
numbered with their archive number. If any one else wants to run an
archive service like this, it would be very useful. Anyone interested
should ask Brian Reid about the availability of his archiving software.
It is very clever, with automatic features to prevent any one person
from using up too much bandwidth (the more you request, the worse your
response time, and breaking up a big request into many little requests
doesn't help). His address is r...@decwrl.dec.com
7. As MINIX gets distributed, it would be very helpful to have people report
on their experiences on various clones. A subject line like:
MINIX on the Southern Wombat 1000
would be appropriate here. In these reports, tell what you configuration
is, how many megahertz you have, printer type, etc. Anyone interested in
collecting these and posting the results as a nice clean table later?
I have gotten hundreds of pieces of mail on MINIX, and many queries about
whether it works on some particular machine. I rarely know, but at some
point if we have a single file telling where it works and where it doesn't
I am sure that would be helpful.
I am going for an airplane ride again. I will be keynote speaker at the
Sixth Symposium on Reliability in Distributed Software and Database Systems
in Williamsburg Va. on March 18. That talk will be about "Reliability in ..."
I am also going to be at Georgia Tech March 10, Yale March 12, and Stony
Brook March 16. When I get back on March 20, I am going to France a couple
of hours later. Conclusion: I won't be answering any mail until April,
and if my previous trip is any guide, the overflow bit on my mailbox will be
set when I get back.
For those of you going to the EUUG conference, I will also be keynote speaker
there on May 13. That talk will be about MINIX. The EUUG conference will be
held on a boat sailing between Helsinki and Stockholm. This will be one of
the few UNIX conferences with its own taxfree shop selling intoxicating
beverages. If the talks get boring, you can go get drunk. Stockholm and
Helsinki are both beautiful cities and well worth visiting.
Andy Tanenbaum (a...@cs.vu.nl)