Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!...@icst-cmr.arpa
From: r...@icst-cmr.arpa (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: SVR3.0 vs BSD4.3
Message-ID: <12414@brl-adm.ARPA>
Date: 15 Mar 88 19:30:28 GMT
Sender: n...@brl-adm.ARPA
Lines: 12
From: Doug Gwyn <g...@brl-smoke.arpa>
SVR3.0 is the first AT&T UNIX system release that I would rate as
technically the equal of, or superior to, 4.nBSD on all major counts.
The *first* one? I thought you were a believer years ago.
(Root Boy) Jim Cottrell <r...@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
Isn't this my STOP?!
Path: utzoo!mnetor!uunet!husc6!hao!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4361@megaron.arizona.edu>
Date: 16 Mar 88 03:02:46 GMT
References: <12414@brl-adm.ARPA>
Reply-To: l...@megaron.arizona.edu (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 18
In article <12...@brl-adm.ARPA> r...@icst-cmr.arpa (Root Boy Jim) writes:
>
> From: Doug Gwyn <g...@brl-smoke.arpa>
>
> SVR3.0 is the first AT&T UNIX system release that I would rate as
> technically the equal of, or superior to, 4.nBSD on all major counts.
>
>The *first* one? I thought you were a believer years ago.
I missed the opener on this one; are you really serious, Doug? What do you
mean by technically superior? A nicer implementation of the disk sched
alg? Or a more reasonable computing environ as defined by the system
call interface? Or something else, somewhere inbetween?
Just curious,
--
Larry McVoy l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7499@brl-smoke.ARPA>
Date: 20 Mar 88 05:32:48 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 50
In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu (Larry McVoy) writes:
>> From: Doug Gwyn <g...@brl-smoke.arpa>
>> SVR3.0 is the first AT&T UNIX system release that I would rate as
>> technically the equal of, or superior to, 4.nBSD on all major counts.
>I missed the opener on this one; are you really serious, Doug?
Of course I'm serious. Consider:
modular region-based virtual memory manager
shared libraries
file system switch
transparent networked file system
STREAMS
network interface library
record locking
reliable signals
windowing utilities
HDB UUCP
in addition to things already found in earlier releases of UNIX System V:
usable system interface specification document
faster, more complete standard C library
somewhat better C compiler
COFF
FIFOs
terminfo
shell layers
shared memory
semaphores
message passing
process locking
vendor support
Berkeley's system has equivalents to some of these, no equivalents to
others, and includes some things like LISP (not Common LISP) and rogue
not found in AT&T's system. Berkeley's terminal handler is nicer-
looking to the user but not as good for the application programmer.
BSD-style job control is somewhat nicer for the user than shell layers,
but this is not available in their Bourne shell. And so on...
When we acquired our first VAX, we had to decide which flavor of UNIX
to run on it. We identified three reasons to prefer the Berkeley variant:
TCP/IP network support
virtual memory for large applications
compatibility for importing sources from other sites,
particularly from the Alpha_1 project (which
for example relied heavily on flexnames).
The only one of these that might still be a factor is the latter,
but our level of concern with importing a single specific application
is much lower now, and in any case that is not a matter of technical
superiority. Portability considerations are much more important, and
UNIX System V is much closer to meeting useful standards than 4BSD.
Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!rutgers!iuvax!bsu-cs!dhesi
From: dh...@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <2423@bsu-cs.UUCP>
Date: 20 Mar 88 16:55:48 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
Reply-To: dh...@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 35
In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
writes:
[arguments why SVR3 is as good as 4.3BSD on all counts]
Here are some things I see under 4.3BSD that I don't see under SVR3,
unless they are either not documented or I somehow missed them. I'm
comparing the full packages, not just the kernels.
job control (stop/restart jobs, get status of jobs and know
one is stopped for tty input)
intelligent echoing to screen (SVR3 seems to blindly echo
everything or nothing, can mess up screen, won't redraw
partially-typed line, won't align tabs on char erase)
intelligent mail handling -- sendmail, MH, biff, vacation
"script" for recording terminal session
"ul" for underlining when printing on various printers
one complete KWIC index for all manuals
symbolic links
long filenames
a user can be in multiple groups
user information lookup ("finger", "lastcomm", "last")
UUCP over TCP/IP links
support for multiple command interpreters with #! as first line of script
dbm library--fast /etc/passwd and /usr/lib/news/history access etc.
context diffs from diff
smarter, friendlier "at" program
A note about UUCP: Although theoretically HDB UUCP is the equal of the
4.3BSD UUCP, I constantly hear horror stories on Usenet about how HDB
UUCP doesn't work right for one reason or another. I don't hear quite
as many horror stories about 4.3BSD UUCP, probably because it has been
better integrated into the rest of the system and has had time to
stabilize.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
Path: utzoo!mnetor!uunet!husc6!bu-cs!bzs
From: b...@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <20768@bu-cs.BU.EDU>
Date: 20 Mar 88 19:12:51 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
Organization: Boston U. Comp. Sci.
Lines: 35
In-reply-to: gwyn@brl-smoke.ARPA's message of 20 Mar 88 05:32:48 GMT
Doug, I tend to agree with you that SVR3 has really pushed SystemV
ahead and is promising to contribute a lot to the Unix community and
improve all variants of Unix as they move towards a common standard.
Other than job control and the user's view of the terminal handler
(both of which are probably reasonably bridged with ksh, so the Bourne
shell's lack is probably becoming moot) I'd still have to point out
the System V file system which is vastly inferior to BSD's rework in
some non-ignorable ways.
I don't see that implementing the BSD file system under SysV would
disrupt much anything either from a user's point of view (it just
gives them long file names) or the system's (it just speeds up access,
improves integrity a lot and reduces fragmentation to the point of
becoming a non-issue.) What's the issue here? Just a matter of time or
is there some real objection to adopting the BSD file system? Anyone
have a handle on this?
Similarly that should immediately give SysV dump and restore and other
utilities (eg. a better fsck), things that would vastly improve the
operational aspects which are very important in this day and age of
people like us having to manage over 100 systems and needing good,
reliable operational tools. Finc etc just don't cut it (do I need
to explain why?)
Also, adopting a standard and top-notch TCP/IP implementation with
several of the needed utilities bundled in is critical to many of
us and would force our hand if lacking.
I would have to suspect that the ATT/SUN merger is going to resolve
these issues, so I guess we wait just a little longer (heck, it's been
12 years now I've been waiting for all this to happen.)
-Barry Shein, Boston University
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7511@brl-smoke.ARPA>
Date: 21 Mar 88 12:25:47 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<20768@bu-cs.BU.EDU>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 40
In article <20...@bu-cs.BU.EDU> b...@bu-cs.BU.EDU (Barry Shein) writes:
>What's the issue here? Just a matter of time or is there some real
>objection to adopting the BSD file system?
I don't think there is any real problem with providing the 4.2BSD
style of disk file system in UNIX System V via the file system
switch. Implementations that currently support the old-style disk
file system will probably continue to do so in order to avoid
forcing the customer to rearrange existing disks when upgrading.
Note that several UNIX System V implementations already use a
different style of disk file system; for example, Silicon Graphics
has an extent-based scheme. The nice thing about the FSS is that
it provides a relatively painless way to migrate from one style to
another, or to provide a special format, e.g. real-time data files,
which may have different needs from general timesharing files.
My evaluation of the 4.2BSD cluster approach is that it works best
if the processor has cycles to spare, and may not be a good choice
for small systems.
>Also, adopting a standard and top-notch TCP/IP implementation with
>several of the needed utilities bundled in is critical to many of
>us and would force our hand if lacking.
Unfortunately, the implementation you probably have in mind is
tightly coupled to sockets. Wollongong developed a STREAMS-based
TCP/IP for AT&T; I don't know how good it is but there is no a
priori reason that a STREAMS implementation couldn't be as good as
one based on sockets.
One thing that a totally-STREAMS version of UNIX System V would
achieve is transparency over "pseudo-tty" channels, so that terminal
ioctls would work right. I've needed this many times on our 4.2BSD
systems and have had to punt on it.
>I would have to suspect that the ATT/SUN merger is going to resolve
>these issues...
Certainly most of us hope so. AT&T is definitely evolving UNIX far
faster than they used to.
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7514@brl-smoke.ARPA>
Date: 21 Mar 88 13:37:04 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<2423@bsu-cs.UUCP>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 109
In article <2...@bsu-cs.UUCP> dh...@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
>writes:
>[arguments why SVR3 is as good as 4.3BSD on all counts]
I said on all MAJOR counts. There are lots of small items on each
system that the other could benefit from. I named some, you named
some, and there are lots more.
> job control (stop/restart jobs, get status of jobs and know
> one is stopped for tty input)
As I mentioned, the System V equivalent is "shell layers", which is
not quite as nice from the user's perspective but it sure disrupts the
system internals less than the 4BSD approach (which has been revised
one way or another at least five times that I am aware of and still
occasionally causes us problems). The 4BSD scheme for various reasons
does not readily fit into System V; I think the scheme worked out for
IEEE Std 1003.1 will probably be included in a future release of UNIX
System V.
> intelligent echoing to screen (SVR3 seems to blindly echo
> everything or nothing, can mess up screen, won't redraw
> partially-typed line, won't align tabs on char erase)
I mentioned this. There is no particular reason most of these features
could not be added to the System V terminal handler, and it would be
useful if they were. Except for the user interface, the System V
terminal handler is clearly superior for most applications, as the
Berkeley developers have acknowledged; I think they've developed a
POSIX-compatible replacement terminal handler but I don't know how
you can get your hands on it.
> intelligent mail handling -- sendmail, MH, biff, vacation
Doesn't matter to me; we use MMDF, $MAILPATH, sysmon, etc.
> "script" for recording terminal session
"Script" screws up the application running under it sometimes. It
could be implemented almost trivially with STREAMS. Somebody should
do so.
> "ul" for underlining when printing on various printers
Another one we don't use. MDQS's line-printer spooler does a much
better job, and our other printers know how to underline.
> one complete KWIC index for all manuals
That might be handy, but UNIX System V is intended to be distributed
as a set of packages, many of them optional, so it is hard to see
how to prepare such a merged index that would be maximally useful.
> symbolic links
Probably coming in a future release. As discussed previously, they
do bring some problems, but are nonetheless probably worth having.
> long filenames
This is tied to the disk filesystem format, and unlike Berkeley,
AT&T chose not to invalidate their customer's existing filesystems.
However, the FSS now provides a mechanism for graceful migration to
an improved filesystem in which longer names would be possible. I
don't know if they're working on it, but undoubtedly it would come
out of the AT&T/Sun merged-UNIX project.
> a user can be in multiple groups
Probably coming in a future release. I hope they fixed the Berkeley
bug that kept me from logging in when the system administrator added
me to my ninth group!
> user information lookup ("finger", "lastcomm", "last")
I don't use these, so no comment.
> UUCP over TCP/IP links
Supported by UNIX System V, last I heard.
> support for multiple command interpreters with #! as first line of script
This is totally unnecessary; if all scripts are executed by a Bourne
shell, it is easy to simulate the #! feature, in fact to generalize
on it. Nevertheless I think AT&T may be adding this kludge to the
kernel exec code in a future release, alas.
> dbm library--fast /etc/passwd and /usr/lib/news/history access etc.
There are other ways to speed up /etc/passwd access that don't have
the drawback of maintaining a separate index file. A good, standard
ISAM would be useful, but dbm ain't it.
> context diffs from diff
This could be added easily enough, and I considered adding it to my
System V emulation package but decided it wasn't particularly useful.
> smarter, friendlier "at" program
Another thing I don't care for; we use MDQS "batch" facilities.
System V has user (non-superuser) crontab support that seems nice.
>A note about UUCP: Although theoretically HDB UUCP is the equal of the
>4.3BSD UUCP, ...
Wrong; theoretically it is superior to 4.3BSD UUCP.
Path: utzoo!mnetor!uunet!husc6!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4441@megaron.arizona.edu>
Date: 22 Mar 88 19:02:34 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA>
Reply-To: l...@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 24
In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Unfortunately, the implementation you probably have in mind is
>tightly coupled to sockets. Wollongong developed a STREAMS-based
>TCP/IP for AT&T; I don't know how good it is but there is no a
>priori reason that a STREAMS implementation couldn't be as good as
>one based on sockets.
It is my personal belief that streams was intended as a _slow_ terminal
"virtualization" (Padlipsky would be proud) mechanism. As such, one
should probably think carefully about the performance aspects of
implementing high bandwidth drivers that use streams. One could (I have
seen it) suggest that all drivers talk through streams interfaces. Seems
like a nice idea (modularity being the buzzword that comes to mind) until
you start counting how many times you say "bcopy(src, dest, len)". This
might be a moot point when we have infinitely fast CPU's and memories :-)
(It should be obvious but I'll drive it home: the streams code that I've
seen copies the data out of the upper level buffer and then into the
lower level buffer [assuming "downward" movement]. The copying dominates
the time spent in the streams drivers. If streams can handle imbedded
pointers in their data then my comments are meaningless.)
--
Larry McVoy l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
Path: utzoo!mnetor!uunet!seismo!rick
From: r...@seismo.CSS.GOV (Rick Adams)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <44269@beno.seismo.CSS.GOV>
Date: 22 Mar 88 19:08:01 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<2423@bsu-cs.UUCP>
Organization: Center for Seismic Studies, Arlington, VA
Lines: 15
Summary: hdb vs. 4.3bsd uucp
In my biased opinion, HDB has 3 major advantages over the 4.3bsd uucp.
1) The Permissions file
2) The Dialers file
3) Subdirectories per site.
4.3 aleady has almost all of the other good ideas the HDB did. The
subdirecories are coming soon. The Dialers are coming soon. The
Permissions file is coming some day.
It is my stated goal to make the 4.3bsd uucp do everything HDB does
without using any of the HDB code.
---rick
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: STREAMS overhead (was: SVR3.0 vs BSD4.3)
Message-ID: <7526@brl-smoke.ARPA>
Date: 22 Mar 88 23:30:40 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11
In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu.UUCP (Larry McVoy) writes:
>(It should be obvious but I'll drive it home: the streams code that I've
>seen copies the data out of the upper level buffer and then into the
>lower level buffer [assuming "downward" movement].
The only data copy that should normally take place is between user-mode
data space and the nearest streams buffer, also between the farther
streams buffer and the net device. Streams module-to-module data
transfer should occur by transferring packet pointers whenever possible.
(I haven't examined SVR3 code to see if this is how it typically does
things.)
Path: utzoo!mnetor!uunet!husc6!bbn!gatech!ulysses!hector!ekrell
From: ekr...@hector.UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <10179@ulysses.homer.nj.att.com>
Date: 23 Mar 88 01:59:55 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu>
Sender: netn...@ulysses.homer.nj.att.com
Reply-To: ekrell@hector (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 15
In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu.UUCP (Larry McVoy) writes:
>(It should be obvious but I'll drive it home: the streams code that I've
>seen copies the data out of the upper level buffer and then into the
>lower level buffer [assuming "downward" movement]. The copying dominates
>the time spent in the streams drivers. If streams can handle imbedded
>pointers in their data then my comments are meaningless.)
Well, now. The streams modules that I've seen so far avoid copying data
as much as possible. Passing a message up or downstream is often
accomplished by just passing pointers to the data.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekr...@ulysses.att.com
Path: utzoo!mnetor!uunet!husc6!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4471@megaron.arizona.edu>
Date: 23 Mar 88 17:09:09 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu>
<10179@ulysses.homer.nj.att.com>
Reply-To: l...@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 16
In article <10...@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>In article <4...@megaron.arizona.edu> I said:
>
>>(It should be obvious but I'll drive it home: the streams code that I've
>>seen copies the data out of the upper level buffer and then into the
>
>Well, now. The streams modules that I've seen so far avoid copying data
>as much as possible. Passing a message up or downstream is often
>accomplished by just passing pointers to the data.
Several people have pointed this out to me. It seems that I have been
exposed to some fairly poorly written streams code and it is that code,
not streams, that is brain-damaged.
--
Larry McVoy l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
Path: utzoo!mnetor!uunet!munnari!kre
From: k...@munnari.oz (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <2050@munnari.oz>
Date: 24 Mar 88 11:19:41 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<7514@brl-smoke.ARPA>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 32
In article <7...@brl-smoke.ARPA>, g...@brl-smoke.ARPA (Doug Gwyn ) writes:
> > job control (stop/restart jobs, get status of jobs and know
> > one is stopped for tty input)
>
> As I mentioned, the System V equivalent is "shell layers",
Doug, you know better than that, shl is at attempt at windows for asr33's
and as such has some advantages and some disadvantages over the bsd use
of job control to attempt to force windows onto asr33's and lookalikes.
But that's not job control. Job control is when I notice that /foobar
is 98% full, and some cretin has a job running that's half way through
extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
(Then "kill -CONT <pid>" later if I can manage to scavenge enough space
to allow the tar to continue. Nb: it matters little if the cretin is
me or not in these circumstances).
> > long filenames
>
> This is tied to the disk filesystem format,
Well, kind of, filenames are tied to the directory format, which has
nothing to do with the rest of the filesystem format (after all,
directories are just files, in both systems).
> > support for multiple command interpreters with #! as first line of script
>
> This is totally unnecessary;
This is so much drivel its not even worth commenting on.
kre
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7542@brl-smoke.ARPA>
Date: 24 Mar 88 20:18:33 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<7514@brl-smoke.ARPA> <2050@munnari.oz>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19
In article <2...@munnari.oz> k...@munnari.oz (Robert Elz) writes:
>But that's not job control. Job control is when I notice that /foobar
>is 98% full, and some cretin has a job running that's half way through
>extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc.
Running under "shl", there is a keyboard-generated signal similar to
TSTP and analogs of fg, bg, etc. That is why I said that "shl" is
the AT&T UNIX equivalent of 4BSD job control. As both of us have
said, each approach has advantages and disadvantages w.r.t. the other.
>(after all, directories are just files, in both systems).
This isn't really true. The kernel's file-system code knows how to
deal with specific directory formats. Similarly for NFS directory access.
>This is so much drivel its not even worth commenting on.
A refutation of my argument against #! would have been useful.
Path: utzoo!mnetor!uunet!vsi!friedl
From: fri...@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <445@vsi.UUCP>
Date: 25 Mar 88 06:31:38 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<7542@brl-smoke.ARPA>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 27
Summary: shell layers do not have signals
In article <7...@brl-smoke.ARPA>, g...@brl-smoke.ARPA (Doug Gwyn ) writes:
< In article <2...@munnari.oz> k...@munnari.oz (Robert Elz) writes:
< >But that's not job control. Job control is when I notice that /foobar
< >is 98% full, and some cretin has a job running that's half way through
< >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
<
< Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc.
< Running under "shl", there is a keyboard-generated signal similar to
< TSTP and analogs of fg, bg, etc. That is why I said that "shl" is
< the AT&T UNIX equivalent of 4BSD job control. As both of us have
< said, each approach has advantages and disadvantages w.r.t. the other.
Shell layers do not involve any kind of signals. When ^Z is hit,
the sxt driver gives control back to channel zero, which is
usually the layer manager (here, /usr/bin/shl). When a user
command to shl asks that a child layer be run, the layer manager
issues an ioctl to the multiplexor to give control to the child's
layer (there is no SIGCONT). One result of this implementation
is that I know of no way for a layer to suspend itself, certainly
not with signals (if anybody else knows how I would love to hear it).
Nevertheless it is not incorrect to equate job-control with shell
layers in a general kind of way -- kre's way just may be more general
than mine :-).
--
Steve Friedl V-Systems, Inc. *Hi Mom*
fri...@vsi.com {uunet,attmail,ihnp4}!vsi!friedl
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4509@megaron.arizona.edu>
Date: 25 Mar 88 20:47:39 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
<7542@brl-smoke.ARPA> <445@vsi.UUCP>
Reply-To: l...@megaron.arizona.edu (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 11
In article <4...@vsi.UUCP> fri...@vsi.UUCP (Stephen J. Friedl) writes:
>Shell layers do not involve any kind of signals. When ^Z is hit,
>the sxt driver gives control back to channel zero, which is
>usually the layer manager (here, /usr/bin/shl). When a user
Which means you could emulate shell layers with pty's. All that is going is
the master side has several slave sides and switches between them. It is
a far cry from job control.
--
Larry McVoy l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm