Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/16/85)
Unix Technical Digest Fri, 15 Mar 85 Volume 1 : Issue 27
Today's Topics:
Administrivia
Dumb question: why is "gethostid" a system call?
Sun keyboard driver?
When does alarm(1)==alarm(INFINITY)?
----------------------------------------------------------------------
Date: Fri, 15 Mar 85 22:57:25 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
This digest has a bit of a hodge-podge in it, because none of the general
topics has enough material for its own digest, and I don't want to just
hang on to it hoping something more comes along. All of this appeared in
the net. groups, so the NETUNIX keyword, but since there is some BSD and
some non-BSD stuff here, etc, I didn't want to put any other keywords on
that someone might use to throw the thing out. Comments? Thanks. Ron.
------------------------------
Date: 12 Mar 85 15:33:03 GMT
From: ado@elsie.UUCP (Arthur David Olson)
Subject: Dumb question: why is "gethostid" a system call?
Thanks to everyone who replied to my question about why 4.2bsd's "gethostid"
is a system call, rather than a function that reads information from a file.
From what I gather, the implementation of networking in 4.2bsd requires that
the kernel know what the host ID is. Berkeley folks created a "sethostid"
system call to allow a privileged program to pass the ID to the kernel.
And with "sethostid" came "gethostid".
Another way of doing things would have been to implement a special device
(named, for example, "/dev/hostid") to which the ID could have been written and
from which the ID could have been read. This would have avoided the addition
of exotic system calls.
--
UNIX is an AT&T Bell Laboratories trademark.
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: 12 Mar 85 17:36:52 GMT
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Subject: Sun keyboard driver?
> #define KIOCSETKEY _IOW(k, 1, struct kiockey)
This is a macro Berkeley introduced that evaluates to the (int)
ioctl code (second argument to ioctl(2)) for ioctl functions that
involve sending data from user process space into the kernel.
The macro is defined in /usr/include/sys/ioctl.h. Unfortunately,
they are making use of a Reiser C preprocessor trick to take the
"k" and make a character constant 'k' out of it (then combine that
with the constant "1" and the sizeof(struct kiockey)). If you are
having trouble, first check that you're #including <sys/ioctl.h>.
One objection I have to the _IOWR macros is that not every ioctl
fits this model. There are some "xt" driver ioctls for which the
sizeof the transfered data simply does not fit the alloted space.
------------------------------
Date: 14 Mar 85 03:37:43 GMT
From: tmt@brunix.UUCP (Tom Talpey)
Subject: When does alarm(1)==alarm(INFINITY)?
This caused trouble for me when I wrote a daemon which used a mailbox
IPC structure (under V7) and which was awakened by SIGTRAPs from requesting
processes. It hung occasionally from races before a pause() and had to
be manually goosed when a single requester was active. My solution was
to set a 1-second alarm at every signal catch and to reset the tick
AFTER a completed pause(). This doesn't eliminate the problem, but the
alarm(1) call most always wakes it up one second later and even if THAT
sequence races, the next one might win, etc etc.
sig_catch(sig) {
signal(sig, sig_catch);
alarm(1);
}
sig_wait() {
signal(SIGTRAP, sig_catch);
signal(SIGALRM, sig_catch);
pause();
alarm(0);
}
This worked quite well for me, modulo the occasional extra pauses, but
the daemon wasn't very time-critical and the disk driver lost more
signals than the race ever did. The code sprouted about three or four
such hooks by the time it worked reliably.
Tom Talpey, Brown University Network Operations; ...brunix!tmt
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)