yip@ztivax.UUCP (Dr Yeung-Cho Ip) (11/12/89)
Hello everyone,
in the last two weeks I was adapting the MINIX amoeba stuff to our FDDI
interfaces (AMD FAST boards). According to the differences between this
interface and the WD Etherplus card (i/o mapped 32-bit-wide frame memory vs.
a memory mapped 8-bit-wide one), I had to rewrite the lowlevel driver
routines (dp8390.c) and had to make minor changes in the amoeba task
(amoeba.c). During the test, I had several difficulties mostly with my own
programs but some with the original amoeba examples and utilities as they
are delivered with the 1.3 PH distribution. (It cost me several hours of
thinking, because in the first place I assumed faults in my own software.)
a) The program "client3" in amoeba/examples has a bug near it's end, which
causes the failing of every file tranfer.
wrong place
for closing
paranthesis
|
|
do { v
if ((n=read(fd1, b, 1024) < 0)) {
printf("Cannot read %s\n", argv[1]);
exit(1);
}
if (write(1, b, n) < 0) {
printf("Cannot write stdout\n");
exit(1);
}
} while (n > 0);
}
To solve this problem correct the faulty line to:
if ((n=read(fd1, b, 1024)) < 0) {
b) Due to the makefile in amoeba/util, the program "master" has not enough
stack space (only 500 Bytes). This results in an "Unexpected Trap" or
something like this. To achieve proper operation I increased the stack
space to 800 bytes.
c) The macro "BUFFERSIZE" in sherver.c is set to 8K bytes. While transfering
large files (for example via "rcp") the sherver on the receiving machine
tries to put a buffer of "BUFFERSIZE" bytes into a pipe. Due to the pipe
size of 7K max. this attempt failes and the whole file transfer results
in a file of 0K length on the receiving machine. To avoid this situation,
you simply have to adjust "BUFFERSIZE" below 7K. (Curiously enough, the
"BUFFERSIZE" in sherver.c is allready a redefinition of a much larger
"BUFFERSIZE" somewhere in the headerfiles with the somewhat sarcastic
remark "/* isn't minix wonderful */". So I guess the author was aware
of the situation. Heaven knows why he used too large a value.)
I hope this posting isn't completely uninteressting to the rest of the net.
Michael Franzen
Michael Franzen, c/o yip@ztivax, Munich