netnews@wnuxb.UUCP (Heiby) (08/08/85)
Unix Technical Digest Thu, 8 Aug 85 Volume 2 : Issue 14
Today's Topics:
4.2bsd 'talk' problem
[f]chmod on 4.2BSD
Auto Call Units
Emulex CS32 terminal controller
following symbolic links in ufs_nami.c
porting software
prep
Quota systems
----------------------------------------------------------------------
Date: Wed, 31 Jul 85 17:33:04 edt
From: allegra!phri!roy (Roy Smith)
Subject: 4.2bsd 'talk' problem
I've just started playing around with the 4.2 "talk" program and
have noticed something strange. If one of the talkers is on a dial-in
line, the program works properly but when talk exits the terminal is left
with the tty modes all messed up (in raw mode, I think, and with lcase
set). If you are on a hardwired terminal, everything works fine.
Anybody have any ideas what is going on?
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Fri, 12 Jul 85 09:48:48 pdt
From: N. K. Krishnan <hplabs!krishnan>
Subject: [f]chmod on 4.2BSD
chmod(1) of a symbolic link changes the mode of the target of
the symbolic link. This is beacuse chmod(2) follows symbolic
links. Is there any problem with chmod(2) not following symbolic
links? If chmod(2) does not follow symbolic links it could be
similar to [f]chown(2). To change mode of the symbolic link
one could use
chmod(name,mode);
To change the mode of the target one could use
fchmod(open(name,openmode),mode);
All of this done with appropriate checking, of course.
-krishnan@hplabs
------------------------------
Date: Tue, 6 Aug 85 11:31:11 cdt
From: ihnp4!uokvax!uokmet!root
Subject: Auto Call Units
Contrary to what you may read anywhere, a "<" at the end of a phone number
may be harmful in a call attempt.
We have a Universal Data Systems (UDS) 801 D/C ACU. With the "<" character
at the end of the phone number, the call always fails. Without it, the call
normally makes it. The solution was verified with the people at UDS.
--
Kevin W. Thomas, Univ. of Oklahoma, School of Meteorology, Norman, OK
UUCP: ...!ihnp4!cuuxb!uokvax!uokmet!kwthomas
------------------------------
Date: Wed, 31 Jul 85 04:18:54 EST
From: john@basser.oz
Subject: Emulex CS32 terminal controller
Further to my earlier pleas for help about this device, I thought
that now that I've got it working I'd let people know about the
two "gotchas" with it.
The first one is not really the device's fault. The driver I started
with worked fine on VMZ's, but it was doing something I personally
wouldn't have written: byte-wide writes to device registers. These
are a bit of a no-no. The VMZ liked them fine, but the CS32 interpreted
them as word writes with the high byte zero. This meant that certain
bits, like transmit interrupt enable, would get cleared rather randomly.
I don't believe the CS32 is at fault here; I can't find it now for
the life of me, but I'm sure I've read in some DEC manual that you
aren't supposed to do byte writes to word device registers (or at least,
the effect is undefined).
The second problem was with the hardware XON/XOFF. The device has
a bit you can set to make receipt of ^S suspend the DMA on that
line, and receipt of ^Q restart it (the control character is still
placed in the receive silo). This is not really optional for normal
applications; with DMA output, if the bit was off you could get a lot
of characters (up to 64 with our kernel) after the ^S, and many devices
don't have that much buffering. And this feature just did not work.
^S suspended the output, all right; but ^Q did NOT restart it. I tried
lots of different tricks, pokes and prods, but there was no way I could
get the DMA to start again. Eventually I called Emulex customer support,
and they told me that it was a bug in the firmware on the controller.
They sent us a Rev C prom set which cured the fault. (We originally
had Rev B.) So if you're buying a CS32, watch out for that. The firmware
is in six 24-pin chips in two rows of three at the right end of the
board, looking at the component side, edge connectors down. They
have little oval paper labels with a three-digit number (on ours, 930-935)
followed by a letter (the same letter on all chips), and the letter is
the revision level.
John Mackin, Basser Department of Computer Science,
University of Sydney, Sydney, Australia
------------------------------
Date: Fri, 19 Jul 85 09:18:19 edt
From: ihnp4!linus!security!jjg (Jeff Glass)
Subject: following symbolic links in ufs_nami.c
I have always been offended by the kludge in namei which limits the
number of symbolic links in a pathname to MAXSYMLINK . Can someone
tell me if this method would work?
1) Have namei allocate space for an array of structs which would have
device numbers and inode numbers as components. The maximum size
of this array would be MAXPATHLEN/2 -- the greatest number of
directories that can appear in a pathname.
2) when a symbolic link is encountered in the pathname, check the array
to see if this symbolic link has been seen before. if so, errno = ELOOP;
else, put the device number and inode number of the symbolic link
into the array.
was this approach considered by the implementors of 4.2bsd, and discarded
for some reason? I suppose I am getting ahead of myself -- first of all,
is this method correct?
/jeff
--
security!jjg@mitre-bedford.ARPA (MIL)
{allegra,ihnp4,utzoo,philabs,uw-beaver}!linus!security!jjg (UUCP)
------------------------------
Date: Mon, 29 Jul 85 10:41:04 edt
From: packard!harvard!cybvax0!fbp (Rick Peralta)
Subject: porting software
I would like pointers on common thngs to look out for when porting
software (4.2/sys V) to/from system III. I realize that the communications
are rather diffrent. I have noticed that some of the include files have
been changed around. For exercise I have started on 'rn' and lastcomm from
net.sources. They seem to be suficiently sophisticated and well written.
I am also intrested in the geneology of UN*X. Is there a text that
discusses this, the people and philosophies behind it ?
Rick ...!cybvax0[!dmc0]!fbp
"A likely story. I don't believe a word of it."
------------------------------
Date: Mon, 29 Jul 85 13:57:10 edt
From: packard!harvard!cybvax0!fbp (Rick Peralta)
Subject: prep
What happened to prep in 4.2 ?
Rick ...!cybvax0[!dmc0]!fbp
------------------------------
Date: Thu, 1 Aug 85 13:32:34 edt
From: allegra!phri!roy (Roy Smith)
Subject: Quota systems
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>, <2494@sun.uucp> <5838@utzoo.UUCP>
The following is a follow-up to an article which appeared in
net.unix-wizards and net.micro.att. In an effort to help get mod.unix back
off the ground, I'm submitting it to the mod group. This started out as a
discussion about 4.2 vs. Sys5 but has mutated into talking about disk quota
systems.
> [...] if disk space is short enough that you *need* quotas, it's probably
> overcommitted already.
True, but non-sequitur. It is nice to talk about buying disks, but
what do you do if you don't have money (or your disk controller is already
maxed out, or whatever)? Given the choice, I'll take more disks anyday,
but you don't always have a choice.
> There is also the related problem of maxima becoming minima: "I'm under
> my quota, so I don't need to clean up yet".
In my years of running Unix systems I've run into two basic kinds
of users (I doubt non-Unix systems are any different). Those that conserve
disk space without having to be told, and those that don't no matter how
much you yell at them. Try putting a up message of the day asking people
to clean up. I'll bet you nickels to inodes that the 3 people you were
*really* aiming the message at will ignore it and you'll get proud letters
from people who had almost no stuff to begin with saying that they've
"removed 5 kbytes, does that help?"
> I have no personal experience with quota systems, but I really wonder if
> they aren't like password aging: a superficially-plausible idea that
> doesn't really work all that well.
I have no experience with password aging, so I don't know if *that*
works, but I have used (but not run) machines with quotas. Sure it's
annoying, but so is running out of disk space 3 times a day. The best way
to work things (if you can afford it) is to have reasonable quotas and a
mechanism whereby people can apply for more space. Most people have stuff
laying around which they could reasonably get rid of; old news articles,
mail back to the year one, scraps of programs which never flew, etc. If
you have a quota system, people tend to clean house more often.
Most universities I've seen have a rule that students are not
allowed access to tapes. This strikes me as pretty stupid. On the one
hand you tell people to keep their disk usage down, but on the other you
deny them access to the best mechanism to do so; migrating files to tape.
On a brighter note, I remember one course I took (using a TOPS-20
system) where each student got some initial allocation and the T.A. had an
additional pool of blocks which he could give away to people in the class
as he saw fit. Midway through the semester, that ran out and he petitioned
the S.A. for more.
It worked well enough. The T.A. could keep a close enough eye on
the class to catch disk abusers, and was responsive enough to give people
more space if (and when) they legitimately needed it. If additional space
allocations have to come directly from some central administration, it
takes too long, which encourages hoarding -- people requesting (and using)
more space long before they need it to make sure they have it when they do.
In that particular case, we were all working on data base systems
and needed huge amounts of space. To get the space we needed, a deal was
worked out with the comp center; in return for unusually large quotas we
promised that we would get all our stuff off the system a few weeks before
the end of the semester when space was really tight.
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)