|
Ch 32 -- SVR4 FAQs
|
UNIX Unleashed, Internet Edition
- 32 -
SVR4 FAQs
by Cameron Laird
What Is SVR4?
It's a variety of the UNIX operating system. The Santa Cruz Operation, Inc. at
<URL: http://www.sco.com/>
or 1-800-726-8649, owns the intellectual property--the trademark, the copyrighted
software, and so on. Contact SCO for details.
SVR4, (pronounced "ess-vee-are-four"; also written at times as SysVr4
"sys-vee-are-four"; or occasionally, "sys-vee") is an acronym
for UNIX System V Release 4. UNIX System Laboratories, or USL, which was an affiliate
of AT&T at the time, first released SVR4 in 1988. Its aims were to incorporate
features of BSD UNIX (the other leading lineage of UNIX in the 1980s) into the System
V mainstream, as well as SunOS's Network File System (NFS), the new POSIX, ABI, and
X/Open standards, and to provide a base for future work, particularly in multi-processing.
USL completed the kernel for Release 4.2 in July 1992. "UNIX" itself is
a trademark licensed exclusively by X/Open (URL: http://www.xopen.org/faqs/faq_brnd.htm),
a unit of The Open Group (URL: http://www.opengroup.org/),
an industry standards organization.
Does SVR4 Matter to Me?
Yes and no. SVR4 is at the center of UNIX operations in the 1990s, but the center
has become a quiet place. Most UNIX users today rely on licenses of SVR4, because
it's the basis for such market-leading brands as Solaris, HP-UX, Irix, and Unixware.
However, most UNIX users do not concern themselves with SVR4, because each of those
same market leaders has differentiated itself from SVR4. Most Sun customers think
of their operating system as Solaris; Hewlett-Packard customers identify with HP-UX;
and so on. There are machines that run SVR4 in a narrow sense, but they are all niche
products, with populations a couple orders of magnitude lower than those of the leaders.
What's the conclusion? Think of these three categories:
- If you're trying to use or administer one of the branded variants of UNIX, treat
it as that brand. If you are a Sun customer, read the Solaris chapter and references
in this book, and, for more information, buy other books on Solaris. For you, SVR4
is of only historical interest.
- If you are a user of one of the niche, narrow-sense SVR4 UNIXes, you're probably
receiving full documentation and good support from your vendor. You're a high-end
customer, you represent a large dollar value, and you should expect plenty of help
from those in a position to give it. This chapter gives a context for your work.
Once you've read it, you should know what questions to ask to uncover the deeper
information you need.
- If you are developing applications that you want to be portable across all SVR4
hosts, consider your decision carefully. SVR4 branding does not guarantee binary
compatibility, so successful porting usually involves generation from portable sources.
SVR4 is a possible target for that sort of development, but POSIX (URL: http://standards.ieee.org/catalog/)
or XPG4 (URL: http://www.rdg.opengroup.org/public/prods/xum4.htm)
or 1170 (URL: http://xoweb.xopen.org/public/tech/roadmap/tr1a.htm)
are better ones for most situations. Read this chapter to learn how the different
standards apply to your situation.
Unless it is declared explicitly, all mentions of SVR4 in the rest of this chapter
have to do with "narrow-sense" SVR4, that is, a release other than the
"branded" ones of Solaris, HP-UX, Irix, and so on.
How Did SVR4 Come To Be?
In 1995, Pierre Lewis wrote the standard online summary history of recent UNIX
varieties for the comp.unix.questions FAQ; see URL: ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/unix/questions/Unix_-_Frequently_
Asked_Questions_%286_7%29_%5BFrequent_posting%5D both for his work, and also
for the references he supplies there. The best single hard-copy publication that
covers the same territory is Salus' A Quarter Century of UNIX, published by
Addison-Wesley.
Who Uses SVR4 (Strict Sense)?
Most vendors and customers of SVR4 are in special situations that make their concerns
much different from those of the mass market.
Who Sells SVR4?
These are the leading vendors of UNIXes promoted as SVR4:
These vendors supply specialized hardware that provides high availability, high
performance, commodity pricing, or a combination of related benefits. One possible
complement to highly differentiated hardware is a well-understood operating system
with an industry reputation for reliability and stability. That's what SVR4 is. When
these vendors promote their products, they're able to concentrate their presentations
on hardware capabilities, because the operating system is already familiar to prospective
customers. The industry is comfortable with SVR4.
Who Are SVR4 Customers?
It's a little more difficult getting a handle on the SVR4 customers than it is
to enumerate the vendors. The numeric majority might still be those using Coherent
and Dell UNIX and other low-end, mostly 80 x 86-based, releases of SVR4 from earlier
in the decade. Few of these vendors remain in the business, and their customer populations
are inexorably falling.
The other principal category of customer for SVR4 is the specialized corporate
information technology employee who needs the special offerings of the vendors listed
in the previous two sections. The dynamics of SVR4 use are quite a bit different
from those of such "evangelical" UNIXes as Linux and FreeBSD. SVR4 users
generally maintain a narrow focus on "getting the job done" and have little
interest in pushing the limits of the operating system as an exercise for its own
sake.
What Can You Do with SVR4?
SVR4 differs little in appearance from most other UNIXes in 1997. With few exceptions,
you can do the same things you do with other UNIXes.
SVR4 Technologies
SVR4 includes:
- System III's FIFOs, or named pipes
- early System V's interprocess mechanisms of shared memory, message queues, and
semaphores
- the SVID (System V Interface Definition) standard API
- shared libraries
- streams
- hardware-supported demand paging
- an ANSI C compiler
- BSD-style networking, including the sockets library, a TCP stack, and Network
File System (NFS)
- eight-bit hygiene, that is, correct codings to allow for international characters
in the ASCII character tables
- ksh
- a degree of support for multi-processing
Programming in SVR4
It feels like modern UNIX; that's the main point. SVR4 does not encompass the
POSIX threads library, but, otherwise, programming SVR4 is like programming almost
any other UNIX.
Programming Strategies for SVR4
Simply because it is so standard, programming SVR4 needn't be confined to C codings.
Csh and ksh are part of the distribution, and freely distributable languages such
as Perl, Tcl, Python, Rexx, Sather, Scheme, and more are readily available. Although
SVR4 is unlikely ever to support the explosive growth of specific and graphical utilities
and products one sees in the Windows world, these "scripting" or "high-level"
languages can bring as much productivity to certain sorts of application development
in the SVR4 world as any environment enjoys.
Is It Okay To Use Shared Libraries?
Yes. There is one point about application development that is specific to SVR4.
One of the technologies that SVR4 makes available is that of shared or loadable objects.
Essentially all modern UNIXes rely on shared objects. There are a number of specific
cases in which using shared objects is not recommended; most have to do with commercial
realities of backward compatibility for HP-UX, Solaris, and Linux. I've had no problems
with shared objects under SVR4, though, and can safely recommend it for generation
of applications in both the development and deployment stages.
When To Use Shared Libraries
You're probably using shared libraries already; they are the default for many
development environments. Here's the story: a traditional approach to generation
of applications is to compile and link into a single file all the machine instructions
that a particular application requires. If you need system routines to translate
from display format to floating-point, or to resolve a symbolic name into a numeric
address, or to calculate a logarithm, the linker sorts all those references, mixes
together all the fragments of machine language that implement them, and writes them
into a "monolithic" file image.
There are other possibilities, though. Imagine a linker that makes a much smaller
executable image, one that includes both the machine language for your source code
and references to other libraries. The operating system can load that smaller
file, and then, when it needs to execute one of the system functions, load that in
also, from a standard location. Even better, in a multi-tasking environment, the
system function your application needs may already be available in memory, because
another process has been using it. There's more: shared libraries can improve the
efficiency of installation, provide a much more convenient solution to certain security
issues, and simplify some aspects of upgrading operating systems.
Shared libraries also have the potential to be an effort-wasting nuisance, if
done improperly. The good news is that SVR4 shared libraries are generally done reliably,
and there's no reason to avoid them. Read 'man ld' and other references
your vendor supplies for details.
Programming in a Standard Style
Let's look at an example. Suppose you're programming at a low level in C, and
need to copy a structure from one location in memory to another. There are a number
of idioms for doing so, but the safest I know is
#include <memory.h>
Ö
struct some_struct *source, *destination;
Ö
(void) memmove(destination, source, sizeof(struct some_struct));
memmove() is part of the 159-1989 ANSI standard for C, and reliance on
it is less hazardous than bcopy() or structure assignment. I'm making a
distinction here between correctness--each of these might be correct, depending on
the requirements of your application--and safety; the latter accounts for robustness,
readability, and maintainability. Intelligent reliance on POSIX and ANSI standards
can go a long way toward making your source code clear and effective.
System Administration in SVR4
Stock SVR4 doesn't have a GUIfied admintool, or smit,
or sam, to structure system administration tasks in a point-and-click paradigm.
It's important that a system administrator with SVR4 responsibility have a complete
set of manuals from the vendor, and also such a reference as the UNIX System Administration
Handbook, by Nemeth et al., or Essential System Administration, by Frisch.
The Prentice-Hall UNIX System V Release 4: Network User's and Administrator's
Guide is also a possibility, depending on the circumstances (it was published
in 1990). It covers almost all the technologies available in any SVR4, apart from
dynamic kernels, but has nothing to say about several of the topics--NNTPSERVER,
NIS, firewalls, and others--that are likely to be important in 1997.
Is There Anything Special To Know About SVR4 Hardware?
If you're using SVR4, you'll be talking with your vendor. I know of no independent
developers of device drivers. There surely are some, but they do not have the prominence
that third parties do for Sun or Linux or Windows products. When SVR4 first appeared,
it was a leader in supporting SCSI and serial devices. The technology underlying
that leadership remains strong, but now that SVR4's market position is within niches
specific to vendors, using it reflects the concerns and priorities of those vendors.
What Is Portage?
One of the most interesting developments in SVR4 technology is Portage (URL:
http://www.consensys.com/portage/pintro.htm),
"a complete integration of UNIX SVR4 with Windows NT," as its vendor advertises
it. For a modest incremental cost, 80 x 86-based WNT users can have a full UNIX development
environment on their existing host, including a choice of command shells, accessible
from the NT Command Prompt.
More Information About SVR4
Getting help from your vendor can hardly be emphasized enough. The SVR4 vendors
are the modern experts on their offerings, and most of them understand the importance
of their customers' success. Ask your vendor for help.
Discussion Groups Available Online
Online discussion groups ("newsgroups," in the vernacular of Usenet)
are the best single mode for continuing education on SVR4. There are many forms:
bulletin boards for regional interest groups, BIX conferences, CompuServe forums,
and others. I find Usenet most useful for System V. Please understand that there's
a large element of personal taste in this; even in the soberest technical groups,
Usenet has a density of noise that many readers can't effectively filter. It also
has the deepest and most precise answers on difficult questions.
Newsgroups
All newcomers to Usenet should begin with news.newusers.questions
(What are newsgroups, and what do I do with them?), and then news.groups.questions
(Which newsgroups talk about particular topics?).
Newsgroups That Talk About UNIX Topics
There are many valuable newsgroups that discuss UNIX topics. The most prominent
are:
For particular specialized domains, check the following:
Newsgroups That Specifically Address SVR4
Both comp.unix.sys5.r4 and comp.unix.sys5.misc
are newsgroups designed to support SVR4 discussion. They are both very low in volume,
though, and particular questions directed to them have only a modest likelihood of
being answered. The comp.bugs.sys5 newsgroup
is even less lively.
Much of the information that comes out about SVR4 appears in the following vendor-specific
newsgroups:
I want to draw special attention to alt.folklore.computers;
at least part of the large and active population for this newsgroup are old-timers
who enjoy reminiscing accurately about how they performed heroic works on obscure
machines. Many of them have detailed and useful knowledge about SVR4. There is much
less traffic at comp.unix.wizards, but
it frequently bears on topics germane to SVR4.
SVR4 on the Web
For system administration issues, start with Celeste Stokely's "UNIX Sysadm
Resources" at URL: http://sunos-wks.acs.ohio-state.edu/sysadm_course/sysadm.html.
Mr. Fiamingo has also done an equally thoughtful "Introduction to UNIX"
located at URL: http://www-wks.acs.ohio-state.edu/unix_course/unix.html.
Books on SVR4
There are a few dozen books that specifically address System V development and
use--far more than almost anyone would want to read. My advice throughout this chapter
has been to program or use the generic facilities at the heart of SVR4, because they're
also familiar to users of other UNIXes. Heed the counsel of your vendor, who probably
knows how to make the best use of the implementation. If you need information beyond
those boundaries, you're likely to find it in some combination of the following:
Building UNIX System V Software, Israel Silverberg; Prentice-Hall, 1994.
Device Driver Interface/Driver-Kernel Interface Reference Manual for Intel
Processors: UNIX System V Release 4; Prentice-Hall, 1992.
The Magic Garden Explained Solutions Manual: The Internals of UNIX System V
Release 4: An Open Systems Design, Berny Goodheart, James Cox; Prentice-Hall,
1995.
Product Overview and Master Index for Intel Processors UNIX System V Release
4 Includes Multiprocessing; Unix System Laboratories, 1992.
System Files and Devices Reference Manual for Intel Processors: UNIX System
V Release 4; Prentice-Hall, 1992.
UNIX System V Release 4: An Introduction, Kenneth H. Rosen (Editor), Richard
R. Rosinski, Farber James M.; Osborne McGraw-Hill, 1996.
Mitch Wright and Samuel Ko make available useful annotated lists of published
hard-copy UNIX reference works at ftp://ftp.rahul.net/pub/mitch/YABL/yabl
and URL: http://rclsgi.eng.ohio-state.edu/Unix-book-list.html,
respectively. They include no editions published after 1993 and 1994, respectively,
but this makes them, if anything, only more useful for working with SVR4, whose technology
hasn't changed materially since that time.
©Copyright,
Macmillan Computer Publishing. All rights reserved.
