Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/14/85)
Unix Technical Digest Thu, 14 Mar 85 Volume 1 : Issue 19
Today's Topics:
auxiliary processor black boxes (3 msgs)
Correct use of scanf
Priority shells, do they work? (3 msgs)
READ versus FREAD and WRITE versus FWRITE ... (2 msgs)
Why no setuid for root in V7 kernel? (3 msgs)
----------------------------------------------------------------------
Date: 6 Feb 85 18:16:52 GMT
From: ss@wanginst.UUCP (Sid Shapiro)
Subject: auxiliary processor black boxes
Hi there folks,
An aquaintence at AT&T told me that in his shop, if one program, for example,
troff, started eating too many cycles, they would "hang a
troff-processor-box" off his vax (or other machine) to handle the troff jobs
- they would be shipped to the box, and when done, they would be shipped back.
That sounds pretty good to me, but he also said that these were proprietary
kinds of boxes, so my question is:
Does anyone do this type of "off-line" processing in general, and
specifically, does anyone use/know of a scribe-processor-box off which might
hang off of a vax running 4.2 (actually Ultrix)?
Any pointers to poeple doing it, or vendors who sell such stuff would be
most appreciated. If I get enough responses, etc., etc.
Thanks,
Sid Shapiro -- Wang Institute of Graduate Studies
[apollo, bbncca, ucadmus, decvax, linus, masscomp]!wanginst!ss
ss%wang-inst@Csnet-Relay.ARPA
(617)649-9731
------------------------------
Date: 12 Feb 85 01:59:35 GMT
From: swd@mcnc.UUCP (Stephen Daniel)
Subject: auxiliary processor black boxes
A company called Avalon out on the west coast makes a unibus
board that you plug into your vax. It has an 8mhz 32016 processor
and 1Mbyte of memory. It comes with a little kernel that talks
to a 4.2bsd device driver (also supplied) so that it may implement all
system calls by talking to a process running on your vax.
It costs about $10K (quantity 1). For an extra $1K you can get a
cross compiler. Then you can have a lot of fun.
You take any compute bound C program whose working set size is
less than one megabyte (paging is expensive for this beast)
and go
acc -o program program.c (run cross compiler)
program -options (run your program on the avalon).
Porting code is very easy. The btye ordering is even the same
as a vax. Except for one gross program, everything we've tried
has just compiled and run the first time. We are in the midst of
expanding the list of programs we run on it, but currently I
think we use it for yacc, lex, ccom (the guts of the C compiler)
and ditroff.
In the past we used it to do some raster processing for an ink jet
printer, but we've since bought a dedicated raster box for that printer.
Raw speed is about .5x an unloaded 780 on typical programs.
This means that with any normal load factor you win big.
More details on request.
Enjoy.
Stephen Daniel (decvax!mcnc!swd) (swd@mcnc)
------------------------------
Date: 13 Feb 85 20:28:31 GMT
From: jbn@wdl1.UUCP
Subject: auxiliary processor black boxes
I like it. But of course you have to pay for an additional UNIX
licence for each board if you want to run any of the delivered UNIX
programs.
------------------------------
Date: 7 Mar 85 04:43:59 GMT
From: fouts@ames-nas.ARPA (Marty)
Subject: Correct use of scanf
The following simple program:
#include <stdio.h>
main()
{
char buf[255];
int r;
setbuf(stdin,NULL);
setbuf(stdout,NULL);
while ((r = scanf("%[^\n]\n",buf)) != EOF) {
printf("scanf returned %d",r);
printf(" and the string %s\n",buf);
}
}
has an interesting behavior problem.
The key to the program is the scanf, which (if I read the
description of scanf in the manual correctly) should return an entire
line of input from stdin into buf each time it is called, except that
once (at the end of file input) it should return EOF, causing the while
loop to exit.
On all of the systems I tested, this is the way it behaved when
STDIN was redirected to be from a file. When STDIN is the tty, an
interesting problem occured. On ALL systems tested, the second line of
input had to be read before the first line was output. For instance, a
session might look like:
(I type) a
(I type) b
(It replies) scanf returned 1 and the string a
(I type) c
(It replies) scanf returned 1 and the string b
etc. A further complication occurs when I try to exit the program
by typing an EOF character. BSD 4.2 systems behave as I thought they
would and exit immediately after the first EOF, as do VMS (3.7)
systems. AT&T System V Release 2, as well as a derivitive from Silicon
Graphics required that I type EOF twice.
I assume that the first bit of behavior is related to a problem
similar to the one exhibited by PASCAL, which has to be an entire line
ahead before it can determine that a line of input has been read,
unless "lazy" keyboard i/o or something similar is implemented.
The second problem seems to be a bug in the semantic
interpretation of EOF on the part of SV and its clones. Both problems
seem to me to be unnecessary deviation from the idea of device
independent i/o, as defined in Unix.
Additionally, three of the four implementations tested stripped
leading spaces from the input. (The string " a", with two spaces
before the a, is returned as "a", in buf.) Only 4.2 returned the
leading space, which is the way the manual appears to claim it should
be done.
What is the "correct" behavior (best behavior?) for the first two
problems? Which way is the correct interpretation for leading spaces?
Please reply to me directly, and I will attempt to summarize for
the net, if there is sufficent interest.
Marty Fouts
fouts@ames-nas
ames!amelia!fouts
------------------------------
Date: 11 Feb 85 17:33:03 GMT
From: hubert@entropy.UUCP (Steve Hubert)
Subject: Priority shells, do they work?
We are thinking about implementing nice priorities at login.
In other words, every user would have a base nice value assigned
to the login shell and its children. We are running 4.2BSD and
virtually everyone uses csh as their login shell. Has anyone tried
this and does it work? I'm hoping that it would allow high priority
users to use the machine whenever they want, lower priority users
could use it only if there weren't a lot of high priority users (or
could use it in slow mode with the high priority users) and so on.
I don't know enough about the scheduling, paging, and swapping
algorithms to know what the effect will be. Will it accomplish
what I want without a lot of overhead or will it cause the system
to thrash with lots of paging and swapping.
We have a vax 750 with 2 RA81's on a single UDA50. 33MB of paging
space on each disk. 3MB of memory, soon to be increased. The mix
of jobs on the system is a lot of troff and TeX jobs, a lot of
long running number crunchers, plus the usual edit jobs to go with
them.
Steve Hubert
Dept. of Stat., U. of Wash, Seattle
{allegra,decvax,ihnp4,ucbvax!lbl-csam}!uw-beaver!entropy!hubert
hubert%entropy@uw-beaver
------------------------------
Date: 20 Feb 85 09:42:52 GMT
From: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Subject: Priority shells, do they work?
Yes you can setup login to give a set of priorities to users. On a system
many years ago we had the default nice as 2 set in the code of login just
before we ran the user's shell. Then we set some programs such as cc and
n/troff to a nice of 3 and the editors [RAND and VI] to a nice of 1. You
can do some sort of variation on that. If you assign a different
nice to a given user, then the changes to n/troff, cc and the editors need
to calculate a "relative" change to the current nice.
Warning: small changes to nice can have powerful effect. We niced a program
at 5 once and it took 6 hours to run.
Dennis Mumaugh
Computer Systems Center
Lisle, Illinois
------------------------------
Date: 16 Feb 85 20:44:28 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: Priority shells, do they work?
> Yes you can setup login to give a set of priorities to users.
In fact, the System V Release 2.0 "login" supports his (undocumented, of
course - this *is*, after all, UNIX, home of the useful but undocumented
feature). Begin the "gecos" field with "pri=<number>" (number may be
positive or negative) and it'll do a "nice(number)" before it asks for
the user's password. (On a heavily-loaded system you might, admittedly,
be able to use this trick to figure out which accounts exist.)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
------------------------------
Date: 7 Mar 85 23:39:52 GMT
From: regisc@tekgvs.UUCP (Regis Crinon)
Subject: READ versus FREAD and WRITE versus FWRITE ...
I would be interested to know in which cases
read/write(fildes, buffer, nbytes)'s
are more time efficient than
fread/fwrite(ptr, sizeof(*ptr), nitems, stream)'s .
Note: A detailed explanation would be welcomed.
Regis CRINON
Tektronix Inc.
(503) 627-6053.
( tektronix!tekgvs!regisc )
------------------------------
Date: 9 Mar 85 06:12:18 GMT
From: tmb@talcott.UUCP (Thomas M. Breuel)
Subject: READ versus FREAD and WRITE versus FWRITE ...
If you read large (> blocksize) items from a file, then read/write
is faster. This is because fread/fwrite use read/write to read
blocks from a file.
Personally, I prefer using stdio for terminal I/O and read/write for
binary file I/O.
Thomas.
------------------------------
Date: 28 Feb 85 18:37:44 GMT
From: jer@peora.UUCP (J. Eric Roskos)
Subject: Why no setuid for root in V7 kernel?
In the V7 kernel, the SUID code under the comment "set SUID/SGID protections"
in sys1.c sets the uid for a SUID file only if u.u_uid != 0.
Does anybody know why this is so? Consider a program that is running SUID
root that execs a program (such as a queueing program for a spooler) which
reads the standard input and writes a file. If the program is writing into
a spool area, the program may be a SUID program which writes the file with
protections of, say, 0600, expecting that another SUID program will be able
to read it. But if these latter programs are supposed to set their user
ids to something other than root, this won't work. Since maknod() fills in
the file's i_uid with u.u_uid, the file will be created with owner root,
and the program that is supposed to read it won't be able to.
Exactly this happens in uucp. There is a fix by rti!trt in the UCB version
of UUCP that tries to recover from this, but it only works if the ruid
(and not just the euid) is root. If only the euid is root, the UUCP fix
is not executed, and furthermore, making it work requires a series of
steps that exactly simulates what would happen if the special case for
uid==0 did not occur.
Thus the question arises... why not do SUIDs for uid==0?
------------------------------
Date: 2 Mar 85 01:37:09 GMT
From: henry@utzoo.UUCP (Henry Spencer)
Subject: Why no setuid for root in V7 kernel?
We concluded quite a long time ago that, whatever the intent of this
code, the refusal to setuid for root was effectively a bug. We fixed
it. No problems. I recommend that everyone else do so.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: 1 Mar 85 22:45:41 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: Why no setuid for root in V7 kernel?
> Thus the question arises... why not do SUIDs for uid==0?
Good question. 4.2BSD and System (III|V) both do. If there's any
problem caused by that, somebody better let us all know real fast.
I suspect it was a philosophical decision - they may not have liked
the idea that running a set-UID program lost root privileges instead of
gaining them.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)