clyde@ut-ngp.UUCP (Clyde W. Hoover) (12/07/83)
I too find the sudden change of signals disturbing. What is the MOST
disturbing is that I can't CONTROL their behavior! What if I WANT my
tty reads to return an error if interrupted? Why can't I do that?
What we need here in an ioctl (fnctl) to set/clear the 'system call
restart' feature, just like the 'close on exec' feature. I am also
upset at the dissapearance of sigset, sighold, sigrelse and all the other
special signal setting routines we were told to use in our VAX code
by the Berkeley boys.
I guess it'll teach me to stick to signal(sig, handler)!
Shouter-To-Dead-Parrots
--
Clyde W. Hoover @ Univ. of Texas Computation Center
Austin, Texas
clyde@ut-ngp.{UUCP,ARPA} clyde@ut-sally.{UUCP,ARPA} ihnp4!ut-ngp!clydeguy@rlgvax.UUCP (Guy Harris) (12/07/83)
A few amusing bits, found from poking at the 4.2 code:
1) If you compile in the binary compatibility feature of 4.2, the old
"signal" system call is left in - if it is used, the 4.1 behavior for
interrupted system calls (which, I believe, is the standard V7/S3/S5
behavior) is preserved. So there are hooks for the old way.
2) There is, however, some code for explicitly whapping processes using
the old job control stuff upside the head - the comment says it's there
to catch those programs. I don't know whether it would have been possible,
or desirable (given the goals they had), to do a backward compatible
interface or not. You can achieve the same effect using the new signal
mechanism.
3) There is a 4.1 compatibility library built, but there is also a System V
compatibility library built - or, at least, that's what I infer from the
directory name. It includes "tmpnam()" and the routines "strcatn", "strcpyn",
etc. - but the "strcatn" routines, etc. were old old old routines which
were renamed "strncat", etc. as the result of a big "let's standardize the
names of the string routines" (and "let's make them unique in the first six
letters so as not to upset 370s running MVS and the like") push in Bell
Labs (check out the "C environment" documents that come with System III
for this). Were they stuck in so that programs from Bell which still hadn't
converted would run? I find no trace of those routines anywhere in the
"libc" source for System V - so 4.2's "S5 compatibility library" is backward
compatible with a release of UNIX (UNIX/TS 1.0?) that System V itself isn't
backward compatible with any more! Also, why was "tmpnam" stuck in but
no others?
Berkeley wanted people to use the new signal stuff (i.e., the stuff in -ljobs)
because it did solve some nasty problems with V6/V7/S3/S5/... signals (the
window of vulnerability :-) between getting a signal and resetting it, lost
information when a system call was interrupted, etc.) but the new new signal
stuff is intended to do the same. Furthermore, if you had a program using
the new signal stuff on 4.1 "read", "write", and "wait" got restarted on
interrupts just like on 4.2, so you had to be a bit careful there (although,
admittedly, if you didn't link it with -ljobs you got the V6/V7/S3/S5/...
behavior). Perhaps there should have been a compatibility library for
old programs, so that if you didn't do anything special you got the new
signal stuff but you could ask for the old stuff if you wanted.
I think the new signal facility is a major improvement (i.e., it means that
signals can be used more reliably, although with the availability of general,
efficient, and reliable IPC the need for them will hopefully diminish), but
perhaps a little more attention should have been paid to backwards
compatibility for the benefit of people moving large systems to 4.2 who
can't afford to immediately plunge in and convert their signal-handling
code - all that would have been necessary would have been to put in a
compatibility library with a "signal()" which calls the backward-compatible
system call and perhaps a "-ljobs" for backwards compatibility.
If, f'rinstance, Ma Bell went to that signal mechanism (they contemplated
putting a signal mechanism like the 4.1 mechanism at one point, or at least
one project did), they'd have to leave some backward compatibility hooks in
because I'd be willing to bet there are a lot of telco applications (PDP-11s
and VAXes supporting telco operations) which depend on the old-style
interrupted system call behavior. Ultimately, they should cut over to the
new style, but a grace period might have been nice. On the other hand, I'll
bet other operating systems have had the same type of problems when converting
from release N to release N+1...
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyshannon@sun.uucp (Bill Shannon) (12/08/83)
Clyde Hoover says, "I am also upset at the dissapearance of sigset, sighold, sigrelse and all the other special signal setting routines we were told to use in our VAX code by the Berkeley boys." Who told you to use that stuff? In the DESCRIPTION section of sigset(3) in the 4.1bsd manual it says, "These functions are only available in this version of UNIX, and should not be used when the mechanisms of signal(2) would suffice, as they would then impair portability." In the BUGS section of sigsys(2j) in the 4.1bsd manual it says, "These facilities are still under development and may change in future releases of the system.... The options and specifications of this facility and the system calls supporting it are thus subject to change." Don't say you weren't warned. And yes, if you want to write portable code you won't use any of the new 4.2bsd signal facilities and you won't depend on either the V7 or the 4.2 signal handling (in terms of interrupting system calls). If you use setjmp/longjmp to try to get around some of these problems in a portable manner you also have to be careful of some of the problems of setjmp/longjmp. On many machines, when you do a longjmp all register variables will be reset to the values they had at the time you did the setjmp, whereas all non-register variables will have the same values they had at the time you did the longjmp. This can cause some very bizarre bugs. I agree that there is no excuse for not providing a backwards compatible signal interface. And while we're at it, how many of you depend on the signal handler getting reset to SIG_DFL when you catch a signal? That was "fixed" in 4.2 and would have to be "unfixed" to provide a backwards compatible signal interface. Bill Shannon Sun Microsystems, Inc.
gwyn%brl-vld@sri-unix.UUCP (12/08/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The 4.2BSD apparent System V compatibility library routines are BOGUS. They are totally unsuitable for importing UNIX System V source code. I don't know who named it but he didn't know what he was doing.
ron%brl-vgr@sri-unix.UUCP (12/08/83)
From: Ron Natalie <ron@brl-vgr> Maybe there was a misunderstanding and they are really a 5BSD compatibility routines. -Ron
edhall%rand-unix@sri-unix.UUCP (12/09/83)
Sounds more like Research Version 5 compatability routines... -Ed
Lepreau@UTAH-20.ARPA (12/09/83)
From: Jay Lepreau <Lepreau@UTAH-20.ARPA>
We were all clearly warned about the libjobs stuff going away.
Excerpt from 4.1 man page:
SIGSYS(2J) UNIX Programmer's Manual SIGSYS(2J)
BUGS
The job control facilities are not available in standard
version 7 UNIX. These facilities are still under develop-
ment and may change in future releases of the system as
better inter-process communication facilities and support
for virtual terminals become available. The options and
specifications of this facility and the system calls sup-
porting it are thus subject to change.
-------ron%brl-vgr@sri-unix.UUCP (12/09/83)
From: Ron Natalie <ron@brl-vgr> That's still no excuse for zapping the behaviour of the "standard" signal behavior (even though you contend that it is a fix). -Ron
crl@pur-phy.UUCP (Charles LaBrec) (12/11/83)
I don't have access to a System III/V machine, so correct me if I'm wrong, but isn't Sys III/V non-backward compatible to V7? The tty driver, the fcntl() call, and changing the names of some library routines comes to mind (index, rindex, strn???). Is it possible to completely emulate V7 behavior in Sys III/V? If not, then what 4.2 did to signals seems to be analogous. Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP
guy@rlgvax.UUCP (Guy Harris) (12/13/83)
I don't have access to a System III/V machine, so correct me if I'm
wrong, but isn't Sys III/V non-backward compatible to V7? The tty
driver, the fcntl() call, and changing the names of some library
routines comes to mind (index, rindex, strn???). Is it possible to
completely emulate V7 behavior in Sys III/V? If not, then what 4.2
did to signals seems to be analogous.
Yes, S3/S5 are not 100% backward compatible with V7, but are about 98-99%
backward compatible. Most of the changes needed to make V7 programs run on
S3/S5 or vice versa are trivial ("index" <-> "strchr" and "rindex" <-> "strrchr"
are commonly done with #defines or -Dindex=strchr; "strn???" didn't change
between V7 and S3 - it changed between some VERY old versions of UNIX and V7/
UNIX/TS 1.0, which changed "strcpyn" and the like to "strncpy"). However,
completely emulating V7/4.1BSD/S3/S5/... signals under 4.2BSD is trickier
(although note that if you used the "-ljobs" library under 4.1BSD "read",
"write", and "wait" got restarted like they do under 4.2); the "easiest" way
is probably to grab the code used by the binary compatibility with 4.1
feature, which turns on a "using old signal mechanism" bit, and use that.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guykvm@basservax.SUN (12/13/83)
I see, so we should make all of our programs retrospectively portable every time there is a new BSD, Mr Shannon? No, I'll stick to UNIX*. My much loved UNIX Users Manual tells me about EINTRs and I believe it.
ron%brl-vgr@sri-unix.UUCP (12/14/83)
From: Ron Natalie <ron@brl-vgr> Two wrongs don't make a right. Two wrights make airplanes. -Ron
davidson@bunker.UUCP (Paul E. Davidson) (12/16/83)
Could anyone out there give an english description/definition of a major and minor device, and what is the relation ship to a hardware devicei. ie disk drive, tape drive, tty).
gwyn%brl-vld@sri-unix.UUCP (12/19/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The major device number selects one of the kernel device drivers and the minor device number selects some unit, disk partition, port, etc. within the specific device family. The numbers vary from system to system.
henry@utzoo.UUCP (Henry Spencer) (12/21/83)
Sounds like 4.2BSD is to UNIX as Ada is to Pascal.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry