July 2000
This section contains a description of the features you will find in the Solaris 8 operating environment.
New Features at a GlanceThe following table briefly describes the new features of Solaris 8.
IPv6For Solaris 7, developers who were interested in getting a first look at IPv6 had to download a prototype from http://www.sun.com/solaris/ipv6. With Solaris 8, IPv6 comes as a supported feature.
This section will look at IPv6 from a software developer's point of view. Additional information may be found in the Network Interfaces Programmer's Guide, and the System Administration Guide, Volume 3 in the Solaris 8 Document Collection. Various books covering IPv6 are also available, including an excellent one by W. Richard Stevens titled UNIX Network Programming, Volume 1, Second Edition [Stevens98].
Reasons to Change to IPv6Since IPv4 is so widespread, why change at all? The development efforts and the logistics of getting a new scheme deployed are definitely not trivial. The predominant reason to change is that the current 32-bit IPv4 address space could be exhausted by 2007. The 128-bit IPv6 address space will allow for 3.4 x 1038 unique addresses. It is estimated that even after introducing inefficiencies based on routing requirements, IPv6 will still be able to provide over 1000 addresses for every square meter on the surface of the earth.
Since a newer protocol was needed to handle a larger address space, the designers of IPv6 took the opportunity to add other improvements. The changes from IPv4 to IPv6 fall primarily into the following categories:
Request For CommentsThe IPv6 standards are documented in Requests for Comments (RFCs) that are available from The Internet Engineering Task Force (IETF). Use the
Stateless Address AutoconfigurationIn IPv4, a node was usually associated with a Class A, B, or C IP address that had to be managed either locally or at a server. For IPv6, stateless address autoconfiguration allows IP addresses to be assigned to a host with minimal configuration. A node may be associated with three types of addresses:
A node always has a link-local address. It may have a site-local address as well as one or more global addresses.
Stateless address autoconfiguration (RFC 2462) defines the mechanism that allows a host to generate its addresses automatically without a server. All three types of addresses are formed by combining a 64-bit prefix and a 64-bit interface ID. The prefix for link-local addresses is
Stateful autoconfiguration allows tighter control over exact address assignments and requires a server. Stateful autoconfiguration will be based on DHCPv6, which is currently in progress. To find out more about DHCPv6, refer to http://www.ietf.org under IETF Working Groups, Internet Area, Dynamic Host Configuration (
IPv6 Header FormatThe IPv6 header format is defined in RFC 2460 (which obsoletes RFC 1883).
Note that the 4-bit priority field in RFC 1883 has been changed to an 8-bit traffic class field in RFC 2460. The flow label field was changed from 24 to 20 bits to compensate.
IPv6 Extension HeadersThe following IPv6 extension headers are currently defined in RFC 2460.
The Authentication and Encapsulation headers are used in Ipsec, which is described in IPsec for IPv4 in this white paper. IPsec for IPv6 will be supported in a Solaris 8 update.
IPv6 Socket Address StructureThe socket address structure in
struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info
*/
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* set of interfaces for a scope
*/
Compared to the structure used in IPv4, we see that
The
The
Note that the
Porting an Application from IPv4 to IPv6For existing applications that do not need IPv6 functionality, no changes to either the binaries or the sources are required. The only exception is code that did not set the
Converting an existing application to support IPv6 functionality can be relatively simple. The white paper titled Porting Networking Applications to the IPv6 APIs provides detailed instructions for simple as well as more complex applications. RFC 2553 (which obsoletes RFC 2133) describes the following basic conversions:
AF_INET -> AF_INET6 sockaddr_in -> sockaddr_in6 gethostbyname() -> getipnodebyname() gethostbyaddr() -> getipnodebyaddr() inet_ntoa() -> inet_ntop() inet_addr() -> inet_pton() Refer to the appropriate man pages to find out about any differences in the parameters passed to the new functions.
Broadcasting Replaced by MulticastingBroadcasting support is not provided in IPv6. This means that any IPv4 application that uses broadcasting must be recoded for IPv6 to use multicasting instead [Stevens98]. For example, ARP has been replaced by neighbor discovery, BOOTP will be handled by DHCPv6 (work in progress), and NTP has been assigned multicast group ID 101 (hex).
Multicasting Will Need to Be RewrittenFor IPv4 applications that use multicasting, conversion to support IPv6 multicasting will require some effort. Section 19.6 of [Stevens98] suggests that the protocol-dependent code may be localized in eight functions.
New Naming Architecture
IPv4 addresses must be added to both
IPv6 addresses are added only to
Note that the order for resolving names is still controlled in
New Socket OptionsThe new socket options associated with IPv6 are covered in Sections 7.7, 7.8, 10.5, 20.8, 24.5, 24.6, 24.7, and 25.4 of [Stevens98]. However, the standards have been evolving. RFC 2133 has been obsoleted by RFC 2553 and an Internet-Draft is currently in progress to replace RFC 2292 (see
There is one new ICMPv6 socket option. Include the header file
There are a number of new IPv6 socket options. Include the header file
The first version of the Advanced Sockets API for IPv6 is covered in RFC 2292. However, changes are being proposed that are covered in the Internet-Draft. Note that
New InterfacesSome of the new interfaces defined for IPv6 are listed below. For a complete list, refer to RFC 2553.
freeaddrinfo(3SOCKET) freehostent(3SOCKET) getaddrinfo(3SOCKET) getipnodebyaddr(3SOCKET) getipnodebyname(3SOCKET) getnameinfo(3SOCKET) inet_ntop(3SOCKET) inet_pton(3SOCKET) ARP Replaced by Neighbor Discovery
arp -a -> netstat -p arp -d -> not available arp -s -> not available The ARP cache operations using
ioctl SIOCSARP -> not available ioctl SIOCDARP -> not available ioctl SIOCGARP -> not available IPv6 DaemonsThe following daemons are associated with Ipv6.
Extensions to Existing UtilitiesWith the underlying changes in IPv6, some changes to user-level utilities have resulted as well.
Note: Existing scripts that process the output of these utilities may break or fail if they cannot handle the new output format. More details may be found in the "IPv6 Extensions to Existing Utilities" section of the System Administration Guide, Volume 3.
tcpdump ProgramIf you prefer to use
tcpdump ether proto 0x86dd tcpdump is available at http://ee.lbl.gov.
IPv6 Address as a Command Line ArgumentThe following list of commands have been extended to accept a literal IPv6 address as a way of communicating with their respective servers:
In addition, if a hostname is provided, a lookup of the name is done.
Transition IssuesFrom a software developer's point of view, IP applications are written as clients and servers. The four possible combinations of client/server and IPv4/IPv6 (as shown in the following figure) are:
The first case (IPv4 Client, IPv4 Server) and the fourth case (IPv6 Client, IPv6 Server) are easy to understand and handle.
The second case, (IPv4 Client, IPv6 Server) and the third case, (IPv6 Client, IPv4 Server) need more care. In either case, a host machine needs to have dual stacks to use both IPv4 and Ipv6.
IPv4 Client, IPv6 ServerSection 10.2 of [Stevens98] provides a good discussion of the IPv4 Client, IPv6 Server case. If the IPv6 server is bound to the wildcard address (
IPv6 Client, IPv4 ServerSection 10.3 of [Stevens98] provides a good discussion of the IPv6 Client, IPv4 Server case. If the IPv6 client uses a resolver that provides an IPv4-mapped IPv6 address, then the dual stack will again handle the communications with either an IPv4 or IPv6 server.
More InformationSolaris 8 Software Developer Collection
Solaris 8 System Administrator Collection
Links:
RFCs:At IETF (http://www.ietf.org) or at RFC Editor (http://www.rfc-editor.org)
Other Documents:
Native LDAPThe Lightweight Directory Access Protocol (LDAP) is an open-standard, platform independent, access protocol based on the X.500 informational model. It is designed to run over TCP/IP (compared to the full OSI stack for X.500) and uses simple string encoding. LDAP servers provide access to a hierarchical Directory Information Tree (DIT) that is made up of entries. An entry has a relative distinguished name (RDN) that is unique among all its siblings and a distinguished name (DN) that is unique in the tree. LDAPv3 (RFC 2251) supports the following operations:
LDAP first appeared in Solaris 7 as a client library that enabled developers to write LDAP applications and allowed users to run LDAP enabled applications. In Solaris 8, native LDAP provides the Name Service switch with back-end support for LDAP based directory service.
LDAP in Solaris 7The LDAP client library was first available in Solaris 7. The
LDAP in Solaris 8Native LDAP provides complete LDAP integration into Solaris 8. LDAP back-end support to the Name Service switch was added. Network administrators can now specify LDAP as the desired name service to directory access by copying the
The following man pages are new in Solaris 8.
The following man pages have been updated with changes to support LDAP.
The C LDAP Application Program InterfaceAt the time of this writing, the C LDAP API is defined in
In addition, note that a number of functions that were defined in RFC 1823 have been marked as deprecated in the draft.
LDAP ServersSun Directory Services 3.1 is a product that includes an LDAP server. It is a separate product and is not bundled with Solaris 8. The iPlanet Advantage Software CD that is bundled with Solaris 8 includes iPlanet Directory Server 4.11 and Solaris Directory Extensions 1.0. For information on these products, see http://www.iplanet.com/products/platform_layer/unified_user_2_1e.html.
More InformationLinks:
RFCs:At IETF (http://www.ietf.org) or at RFC Editor (http://www.rfc-editor.org)
Java 2 SDK for SolarisThe Java 2 SDK, Standard Edition version 1.2.1_04, provides substantially increased scalability and performance compared to the 1.1 releases, especially for server-class applications. The Java 2 SDK includes these enhancements:
Java 2 has replaced JDK 1.1 as the default JDK in the Solaris 8 operating environment. JDK 1.1.8_09 is still available for applications that encounter incompatibility with the default Java 2 SDK.
Java PlatformSecurity Enhancements
Swing Classes
Java 2D APIs
Accessibility
Drag and Drop
Application Services
Collections
Extensions Framework
JavaBeans Architecture Enhancements
Input Method Framework
Version Identification
RMI Enhancements
Serialization Enhancements
Reference Objects
Audio Enhancements
Java IDL
JAR Enhancements
JNI Enhancements
Reflection Enhancements
JDBC Enhancements
Performance Enhancements
Floating Point Changes
More InformationSolaris 8 Software Developer Collection
Links: Networking Enhancements
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IP Hdr | AH | TCP or UDP Hdr | Data |
The authentication protection covers the entire IP datagram, with the exception of mutable fields with unpredictable values at the destination (from IP Hdr to TCP data in the example above). Current authentication algorithms include HMAC-MD5 and HMAC-SHA-1. See the authmd5h(7M), authsha1(7M), and ipsecah(7P) man pages for details.
The ESP is defined in RFC 2406 and provides the following:
As with AH and other extension headers, the ESP header is inserted between the IP header and the transport header as illustrated in the following example.
| IP Hdr | ESP | TCP or UDP Hd | Data | ESP Trailer | ESP Auth |
The data between ESP and ESP Auth is encrypted. Current encryption algorithms include DES-CBC and Triple-DES-CBC. See the encrdes(7M), encr3des(7M), and ipsecesp(7P) man pages for details. Because of United States export control laws, the encryption strength on ESP is weaker for versions of Solaris sold outside the United States and Canada.
A system-wide protection policy may be used to secure existing applications. The following components are involved with setting this up.
ipsecconf(1M) |
Configure system wide IPsec policy. |
ipseckey(1M) |
Manually manipulate an IPsec Security Association Database (SADB). |
Print-friendly Version
ipsecconf(1M)ipsecconf(1M) is used to configure the system-wide protection policy. The configuration file /etc/inet/ipsecinit.conf can be used to set system-wide policies automatically at boot time. Each policy entry contains three parts:
{pattern} action {properties}
The {pattern} field allows the following to be specified:
The {properties} field allows the following to be specified:
For the complete syntax, refer to the ipsecconf(1M) man page for details and examples.
ipseckey(1M)ipseckey(1M) is used to manually manipulate an IPsec Security Association Database (SADB) and set up keys. The list of commands includes:
add |
Add an SA |
update |
Update SA lifetime |
delete |
Delete a specific SA from a specific SADB |
get |
Look up and display a security association from a specific SADB |
flush |
Remove all SAs for a given SA_TYPE or all SAs for all types |
monitor |
Continuously report on any PF_KEY messages |
dump |
Display all SAs for a given SA type or display all SAs |
save |
Snapshot a particular SA type |
help |
Print a brief summary of commands |
Refer to the ipseckey(1M) man page for details and examples.
HMAC-MD5 128 bits (16 bytes)
HMAC-SHA-1 160 bits (20 bytes)
DES-CBC 64 bits. 56 bit key, plus 8 parity bits. (8 bytes)
Triple-DES-CBC 192 bits. Three concatenated DES keys. (24 bytes)
The keys entered for DES-CBC and Triple-DES-CBC will have the correct parity applied when the keys are used. Keys may look different after parity is applied.
The ipseckey(1M) man page states that keys are expressed as a string of hexadecimal digits with an optional "/" at the end. The value following the "/" is an optional decimal "mask" that specifies the number of bits in the key. Normally, keys of the proper length are entered and the optional decimal "mask" may be omitted. Note that "0x" should not be used at the start of the string.
The system-wide protection policy applied using ipsecconf(1M) relies on configuration by the system administrator without the application being aware of IPsec. New applications may be written to set the protection policy on a per-socket level. As described in the ipsec(7P) man page, the IP_SEC_OPT socket option is used to set per-socket IPsec policy. The structure used for an IP_SEC_OPT request is:
typedef struct ipsec_req {
uint_t ipsr_ah_req; /* AH request */
uint_t ipsr_esp_req; /* ESP request */
uint_t ipsr_self_encap_req; /* Self-Encap request */
uint8_t ipsr_auth_alg; /* Auth algs for AH */
uint8_t ipsr_esp_alg; /* Encr algs for ESP */
uint8_t ipsr_esp_auth_alg; /* Auth algs for ESP */
} ipsec_req_t;
An application should use the getsockopt(3SOCKET) or the setsockopt(3SOCKET) call to manipulate IPsec requests. For example:
#include <sys/socket.h> #include <netinet/in.h> #include <net/pfkeyv2.h> /* For SADB_*ALG_* */ /* .... socket setup skipped */ rc = setsockopt(s, IPPROTO_IP, IP_SEC_OPT, (const char *)&ipsec_req, sizeof (ipsec_req_t));
The per-socket policy may be used on its own without ipsecconf(1M) or it may be used to bypass a system-wide policy. Either way requires the use of ipseckey(1M) and keyboard entry. For more details on per-socket policy, refer to the ipsec(7P) man page.
ifconfig(1M)To support IPsec, the following command line security options have been added to ifconfig(1M):
auth_algs |
Enables IPsec AH for a tunnel with the authentication algorithm specified. |
encr_auth_algs |
Enables IPsec ESP for a tunnel with the authentication algorithm specified. |
encr_algs |
Enables IPsec ESP for a tunnel with the encryption algorithm specified. |
snoop(1M)The snoop command can now parse AH and ESP headers. Since ESP encrypts its data, snoop cannot see encrypted headers protected by ESP. AH does not encrypt data, so traffic can still be inspected with snoop. The snoop -V option can show when AH is in use on a packet. See the snoop(1M) man page for more details.
At IETF (http://www.ietf.org) or at RFC Editor (http://www.rfc-editor.org)
You can keep track of the latest developments by looking under IETF Working Groups, Security Area, IP Security Protocol (ipsec).
Ideally, applications should function seamlessly in all environments, but we all know that this is not the reality. The next best step and well-accepted practice is interoperability between heterogeneous protocols.
The Class II logical link control driver resides in the kernel and interfaces network software to Local Area Networks supporting a variety of protocols (NetBIOS, SNA, OSI, for example).
Multiple and different protocol stacks can operate simultaneously over one or more Local Area Networks.
The LLC2 driver is accessed by standard UNIX STREAMS functions.
Streams-based device drivers that support TCP/IP and other streams-based networking protocol suite implementations support Version 2 of the Data Link Provider Interface (DLPI). DLPI V2 enables a data link service user to access and use any of a variety of conforming data link service providers without special knowledge of the provider's protocol. Specifically, the interface supports Ethernet, X.25 LAPB, SDLC, ISDN LAPD, CSMA/CD, FDDI, token ring, token bus, Bisync, and other datalink-level protocols.
This version of the LLC2 driver includes support for both connectionless and connection-oriented logical link control Class II operations for Ethernet, Token Ring, and FDDI adapters. The network adapters are accessed through the appropriate Solaris MAC layer driver.
The new LLC2 driver support is implemented by the following Solaris packages:
SUNWllc |
LLC2 driver and its initialization programs |
SUNWllcr |
LLC2 driver configuration and start-up files |
SUNWllcx |
LLC2 64-bit driver |
llc2(7D)
llc2(4)
llc2_autoconfig(1)
llc2_config(1)
llc2_stats(1)
llc2_loop(1M)
dlpi(7P)
sendmail 8.9.3 Configuration FileThe following information is repeated from the "What's New with sendmail" section in the System Administration Guide, Volume 3. Version 8.9.3 of sendmail has been included with the Solaris 8 release. Following is a list of the important changes that are included in Version 8.9.3:
MaxHeadersLength, limits the length of the sum of all header lines in a given message. The default value is 32,768 bytes. Incoming messages with headers that exceed this value are rejected.
/etc/default/sendmail can be used to store options to start sendmail, rather than adding these options to the init script. The file makes it easier to upgrade systems, since the init scripts do not need to change.
mail.local program has been extended to use the Local Mail Transfer Protocol. The protocol allows error codes to be returned for each recipient, so that the message is resent to just the recipients that did not receive the message and not re-queued to all of the recipients. This protocol was added to sendmail in the Solaris 7 release.
/usr/bin/praliases, can be used to turn the data in the alias database into plain text. If an argument is included on the command line, the command prints a key:value pair if the argument matches a key.
smrsh can be used to limit the number of commands that can be run using the "|program" syntax of sendmail. Only programs included in /var/adm/sm.bin can be run if this feature is enabled. Adding FEATURE(`smrsh') in the main configuration file enables this feature (see /usr/lib/mail/README for details).
vacation program:
-f can be used to select an alternate database instead of ~/.vacation.ext
-m can be used to select an alternate message file instead of ~/.vacation.msg
-s can be used instead of the UNIX From line to specify the reply address in the incoming message.
mailx program allows for the From: header to be used as the basis of the sender instead of the envelope sender. This change makes mailx work like mailtool and dtmail.
The Service Location Protocol (SLP) is an Internet Engineering Task Force (IETF) protocol for discovering shared resources (such as printers, file servers, and netcams) in an enterprise network. SLP provides a simple yet robust framework that network clients can use to dynamically discover their servers. This method is easier to use and more reliable than static configuration by either configuration files or name services, and lessens the need to create complex graphical administration tools.
SLP (RFC 2608) defines three types of agents:
The Solaris 8 operating environment contains a full implementation of SLP that includes APIs that enable developers to write SLP-enabled applications, and provides system administrators with a framework for ease-of-network extensibility.
Included are developer APIs in C and Java, both of which provide full access to the protocol. The libslp library provides the following routines:
SLPOpen(3SLP) |
Open an SLP handle |
SLPClose(3SLP) |
Close an open SLP handle |
SLPReg(3SLP) |
Register a service advertisement |
SLPDereg(3SLP) |
De-register a service advertisement |
SLPDelAttrs(3SLP) |
Delete attributes |
SLPFindSrvTypes(3SLP) |
Return service types |
SLPFindSrvs(3SLP) |
Return service URLs |
SLPFindAttrs(3SLP) |
Return service attributes |
SLPGetRefreshInterval(3SLP) |
Return the maximum allowed refresh interval for SAs |
SLPFindScopes(3SLP) |
Return list of configured and discovered scopes |
SLPParseSrvURL(3SLP) |
Parse service URL |
SLPEscape(3SLP) |
Escape special characters |
SLPUnescape(3SLP) |
Translate escaped characters into UTF-8 |
SLPGetProperty(3SLP) |
Return SLP configuration property |
SLPSetProperty(3SLP) |
Set an SLP configuration property |
slp_strerror(3SLP) |
Map SLP error code to message |
SLPFree(3SLP) |
Free memory |
For more information, refer to the slp_api(3SLP) man page and RFC 2614.
For system administrators, the following interfaces are available:
slpd(1M) |
A daemon process that acts as either a DA or an SA server |
slp.conf(4) |
Configuration file for Service Location Protocol agents |
slpd.reg(4) |
Serialized registration file for the service location protocol daemon (slpd) |
For more information, see the Service Location Protocol Administration Guide.
In addition, snoop has also been modified to parse SLP messages; a new filter slp has been added to filter only SLP messages.
At IETF (http://www.ietf.org) or at RFC Editor (http://www.rfc-editor.org)
You can keep track of the latest developments by looking under IETF Working Groups, Internet Area, Service Location Protocol (svrloc).
Network Time Protocol (NTP) provides both precise time and network clock synchronization across a network for use in distributed computing environments. The following commands and APIs were introduced in Solaris 2.6:
xntpd(1M) - Network Time Protocol daemon. The daemon can operate as either a client or a server. xntpd is a complete implementation of the NTP version 3 standard, as defined in RFC 1305. It also retains compatibility with versions 1 and 2 servers as defined by RFC 1059 and RFC 1119, respectively. The default configuration file name is /etc/inet/ntp.conf. Sample configuration files may be found in the same directory under ntp.client and ntp.server.
ntpdate(1M) - Set the date and time by polling NTP servers. It can be run on a regular basis from cron(1M) as an alternative to running a daemon.
ntpq(1M) - Standard Network Time Protocol query program
ntptrace(1M) - Trace a chain of NTP hosts back to their master time source
ntp_gettime(2) - Get local clock values
ntp_adjtime(2) - Adjust local clock parameters
In Solaris 8, NTP is upgraded from 3.4y to 3-593e and includes the following new features:
ntpdate(1M) - New flags:
-B flag to force time to be slowed using adjtime(2), even if the offset is greater than 128 ms
-q flag to query only, not setting the clock
-v flag to be verbose, and include the version in logging
xntpd(1M) - New -A flag to disable authentication mode
xntpdc(1M) - A new daemon control program
For more information, refer to the following sections in the System Administration Guide, Volume 2.
At IETF (http://www.ietf.org) or at RFC Editor (http://www.rfc-editor.org)
The DVD video specification based on Universal Disk Format (UDF) provides new applications with a technology that offers broadcast-quality video, high-quality sound, and richness in interactivity.
Solaris 8 supports UDF on the following media:
Implemented by the following Solaris packages:
SUNWudfr - 32-bit kernel component
SUNWudfrx - 64-bit kernel component
SUNWudf - -/usr component
Available for SPARC and IA Platforms.
Solaris 8 Installation Collection, under What's New in the Solaris 8 Operating Environment, What's New: A Closer Look
Solaris 8 System Administrator Collection, under System Administration Guide, Volume 1, Managing File Systems (Overview)
mount_udfs(1M)
labelit_udfs(1M)
mkfs_udfs(1M)
Allows the NFS server to log file operations (what, when, who).
Configuration options:
logformat=basic|extended)
Logging is particularly useful to keep track of FTP archive downloads.
Configuration files:/etc/nfs/nfslogtab - /etc/nfs/nfslog.conf - /etc/default/nfslogd
Solaris 8 System Administrator Collection, System Administration Guide, Volume 3
nfslog.conf(4)
nfslogd(1M)
share_nfs(1M){log=tag}
With the Extended Memory File System (XMEMFS):
Implemented by: mount_xmemfs(1M)
mount -F xmemfs -o size=5g xmem /mnt
The actual size of the file system will be rounded up to the next multiple of the physical pagesize.
mount_xmemfs(1M)
xmemfs(7FS)
mmap(2)
On previous Solaris versions, every time a file was accessed, its access time (atime) was also updated on disk. Specifically, the UFS filesystems were mounted (by default) with normal access time (atime) recording.
Solaris 7 introduced the -o noatime option, which turns off access time recording. This option might be sufficient for some systems, but other systems do require the access time to be recorded, but do not need an immediate update. Therefore, a new option (-o dfratime) has been introduced in Solaris 8 to simply defer access time recording.
Some performance improvement can be achieved in some very I/O-busy systems by deferring the atime updates. When deferred, atime updates to disk do not occur until the disk is accessed for some other reason.
Deferring access time recording may reduce disk activity enough to give the physical disk a better chance to spin down. This would help meet EPA Energy Star requirements.
Implemented by: mount_ufs(1M)
Options:
-o dfratime |
Allows deferring of access time recording |
-o nodfratime |
Disables deferring of access time recording |
-o noatime |
Turns off access time recording completely (Solaris 7 feature) |
mount_ufs(1M)
stat(2)
utime(2)
ls(-t,-u)
See also the section New mount_ufs(1M) Option in this white paper.
File systems can now be unmounted even when they are "busy". This is particularly useful when the file server is dead or broken.
At the command line level, this is accomplished by umount \f.
At the programming interface level, there is a new umount2(2) function, which accepts a flag argument (MS_FORCE). The previous umount(2) function is still supported as a wrapper.
Applications with open files in the file system being (forcibly) unmounted will get EIO errors.
umount(1M)
umount(2)
umount2(2)
This section describes new tools in the Solaris 8 operating environment for monitoring and improving system performance and scalability.
apptraceThis new application debugging tool enables application developers and system support personnel to debug applications by providing tracing calls to Solaris shared libraries. The apptrace tool provides more reliable call tracing than the previously available sotruss command. It also provides better display of function arguments, return values, and error cases for any Solaris library interface.
An important feature of apptrace is that it does not require any modification of the application being traced. The trace output can be on a single line per call or it can be multiple lines per call in order to make it more readable. Public interfaces are printed in human-readable form; private interfaces are typically only printed in hexadecimals. The following is an example of apptrace output.
example% apptrace micro_httpd micro_httpd - libc.so.1:atexit(func = 0xff3ca6e8) = 0x0 micro_httpd - libc.so.1:atexit(func = 0x11738) = 0x0 micro_httpd - libc.so.1:printf(HTTP/1.0 500 Internal Error format = 0x11be8, ...) = 29 micro_httpd - libc.so.1:printf(Server: micro_httpd format = 0x11c08, ...) = 21 micro_httpd - libc.so.1:time(tloc = 0x0) = 0x3835688e micro_httpd - libc.so.1:gmtime(clock = 0xffbd630c) = 0xfedc0568 micro_httpd - libc.so.1:strftime(s = "Fri, 19 Nov 1999 15:", maxsize = 0x64, format = "%a, %d %b %Y %H:%M:%", timeptr = 0xfedc0568) = 0x1d micro_httpd - libc.so.1:printf(Date: Fri, 19 Nov 1999 15:11:10 GMT format = 0x11c38, ...) = 37 micro_httpd - libc.so.1:printf(Content-type: text/html format = 0x11c50, ...) = 25
Some of the options are:
-f |
Follows all children created by fork(2) and also print truss(1) output on each. This option will also cause a 'pid' to be output on each truss(1) output line. |
-t [!]call,.../td>
| Traces or excludes function calls. Those calls specified in the comma-separated list call are traced. If the list begins with a "!", the specified function calls are excluded from the trace output. The use of shell style wildcards is allowed. |
apptrace can also be directed to follow forked child processes by using the -f option. The default is \t*.
busstatA new system monitoring tool, busstat, provides access to bus-related performance counters on supported SPARC platforms. These performance counters allow for the measurement of statistics like hardware clock cycles, DMA, and cache coherency transactions on a multiprocessor system. Each bus device that supports these counters can be programmed to count a number of events from a specified list. Each device supports one or more Performance Instrumentation Counters (PIC) that are capable of independently counting events.
Currently, only UE3x00-6x00 system controllers, address controllers, memory controllers, SBUS interface chips, and PCI interface chips have these counters implemented.
prstatThis new tool examines all active processes on the system and reports various statistics such as number of processes, LWPs, load average, and LWPs per process. The prstat tool can also be used to summarize CPU and memory usage.
The -m option reports microstate process accounting information like, percentage of time the process has spent processing system traps (TRP), text page faults (TFL), data page faults (DFL), waiting for user locks (LCK), and waiting for CPU or latency time (SLP).
example% prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 165 root 3936K 2368K sleep 48 0 0:00.07 0.4% automountd/5 271 root 16M 14M sleep 59 0 0:27.51 0.3% Xsun/1 .... .... .... ..... ..... ... ... ....... .... ....... Total: 110 processes, 233 lwps, load averages: 0.04, 0.14, 0.12
Some of the supported options are:
-a |
Report information about processes and users. In this mode prstat displays separate reports about processes and users at the same time. |
-c |
Print new reports below previous reports instead of overprinting the previous one. |
-m |
Report microstate process accounting information. In addition to all fields listed in -v mode, this mode also includes the percentage of time the process has spent processing system traps, text page faults, and data page faults, waiting for user locks, and waiting for the CPU (latency time). |
vmstatA new flag -p is added in Solaris 8. This option reports page-ins, page-outs, and page-frees by type of pages: executable, anonymous memory, and file system.
example% vmstat procs memory page disk faults cpu r b w swap free re mf pi po fr de sr s0 s6 -- -- in sy cs us sy id 0 0 0 433208 7520 8 33 17 4 6 0 2 1 0 0 0 201 462 182 5 1 94
sortA faster sort command enables more efficient sorting of large data sets. The new -S switch can be used to specify the maximum amount of swap-based memory to be used for sorting.
Solaris 8 has introduced a new API for polling on file descriptors. It allows fast polling on a large number (thousands) of descriptors, especially when polling the same set of descriptors over and over again.
The /dev/poll driver is a special driver that lets users monitor multiple sets of polled file descriptors. By using the /dev/poll driver, users can poll large numbers of file descriptors very efficiently. Access to the /dev/poll driver is provided through open(2), write(2), and ioctl(2) system calls.
Writing an array of pollfd structures to the /dev/poll driver has the effect of adding these file descriptors to the monitored poll file descriptor set represented by the fd. Users wishing to monitor multiple file descriptor sets should open the /dev/poll driver multiple times. Each fd corresponds to one set. The pollfd structure entry is defined as follows:
struct pollfd {
int fd;
short events;
short revents;
}
The DP_POLL ioctl is used to retrieve returned poll events that occured on the file descriptors in the polled set represented by fd. arg is a pointer to a devpoll structure, which is defined as follows:
struct dvpoll {
struct pollfd* dp_fds;
int dp_nfds;
int dp_timeout;
}
The dp_fds points to a buffer that is used to hold an array of returned pollfd structures. The dp_nfds field specifies the size of the buffer in terms of the number of pollfd entries it contains; dp_nfds also indicates the maximum number of file descriptors on which a user is interested in getting poll information. If there are no interesting events on any of the polled file descriptors, the DP_POLL ioctl call waits dp_timeout milliseconds before returning. If dp_timeout is 0, the ioctl call returns immediately. If dp_timeout is -1, the call blocks until an interesting poll event is available or the call is interrupted.
The DP_ISPOLLED ioctl allows users to query if a file descriptor is already in the monitored set represented by a file descriptor. The arg is a pointer to a polled structure. The fd field of the pollfd structure indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1 if the file descriptor is in the set. The events field contains the currently polled events. The revents field contains 0. The ioctl returns 0 if the file descriptor is not in the set. The pollfd structure pointed to by pfd is not modified. The ioctl returns a -1 if the call fails.
More information and examples on the use of /dev/poll driver can be found in the poll(7d) man page.
High-resolution timers bypass the traditional 10-millisecond clock interface to expose the granularity of the physical clock interrupt from the hardware. High-resolution timers are accessed with the POSIX clock type CLOCK_HIGHRES. The new CLOCK_HIGHRES is documented in the clock_settime(3RT) and timer_create(3RT) man pages.
clock_settime(3RT) |
No effect for CLOCK_HIGHRES. |
clock_gettime(3RT) |
Get the amount of time since some arbitrary time in the past. |
clock_getres(3RT) |
Get the resolution of the high-resolution timer. |
timer_create(3RT) |
Create a timer and define the asynchronous notification that will occur when the timer expires. |
time_settime(3RT) |
Sets the time until the next specified expiration of the timer. The time is specified in nanoseconds but the actual granularity is determined by the hardware platform. |
For timers created with a clock_id of CLOCK_HIGHRES, the system will attempt to use an optimal hardware source. This may include, but is not limited to, per-CPU timer sources. The actual hardware source used is transparent to the user and may change over the life of the timer. For example, if the LWP that created the timer changes its processor binding or its processor set, the system may elect to drive the timer with a hardware source that better reflects the new binding. Timers based on a clock_id of CLOCK_HIGHRES are ideally suited for interval timers that have minimal jitter tolerance.
The resolution is dependent on the hardware source. On the UltraSPARC, the resolution is the reciprocal of the processor clock rate. For example, a 250 MHz UltraSPARC would have a CLOCK_HIGHRES granularity of 4 nanoseconds.
The problem of priority inversion with mutual exclusion locks may be solved using a technique called priority inheritance. Solaris 8 implements the following POSIX realtime extensions that were not supported in previous releases.
The following functions no longer simply return ENOSYS:
pthread_mutex_getprioceiling(3THR) |
Return the current priority ceiling of a mutex |
pthread_mutex_setprioceiling(3THR) |
Change the priority ceiling of a mutex |
pthread_mutexattr_getprotocol(3THR) |
Get the protocol attribute of a mutex attribute object |
pthread_mutexattr_setprotocol(3THR) |
Set the protocol attribute of a mutex attribute object |
pthread_mutexattr_getprioceiling(3THR) |
Get the prioceiling attribute of a mutex attribute object |
pthread_mutexattr_setprioceiling(3THR) |
Set the prioceiling attribute of a mutex attribute object |
The following options are defined in unistd.h:
_POSIX_THREAD_PRIO_INHERIT |
The priority inheritance option is supported |
_POSIX_THREAD_PRIO_PROTECT |
The priority protection option is supported |
The following protocol values are supported by pthread_mutexattr_setprotocol(3THR) and pthread_mutexattr_getprotocol(3THR):
PTHREAD_PRIO_NONE |
A thread's priority and scheduling are not affected by the mutex ownership. |
PTHREAD_PRIO_INHERIT |
A thread runs with the highest priority of any thread waiting on any of the mutexes owned by that thread. |
PTHREAD_PRIO_PROTECT |
A thread runs with the higher of its priority or the highest priority ceiling of all mutexes it owns. |
Priority inheritance and priority ceiling locks should be used with bound threads. Unbound threads are unsuitable for the needs of real-time applications. Use the pthread_attr_setscope(3THR) to create a bound thread (PTHREAD_SCOPE_SYSTEM) or an unbound thread (PTHREAD_SCOPE_PROCESS).
The following interfaces have been added in Solaris 8 to make priority-inheriting locks more robust to deal with the death of a mutex owner. These extensions are Sun-specific and are not defined by POSIX.
pthread_mutexattr_setprotocol(3THR) |
The behavior on owner death depends on the robustness attribute of the mutex. |
pthread_mutex_lock(3THR)pthread_mutex_trylock(3THR) |
Error values EOWNERDEAD, ENOTRECOVERABLE, and ENOMEM have been added. See man page for details. |
pthread_mutex_consistent_np(3THR) |
New function to make a mutex consistent after owner death. |
pthread_mutexattr_getrobust_np(3THR)pthread_mutexattr_setrobust_np(3THR) |
New functions to get and set the robustness attribute of a mutex attribute object. |
For more information, see the Multithreaded Programming Guide in the Solaris 8 Document Collection.
The STREAMS framework enhancements in the Solaris 8 operating environment provide more deterministic response times for real-time processes by ensuring that STREAMS processing uses a priority that does not conflict with the user process priority. No changes to application code are required to take advantage of these enhancements. However, non-compliant modules or drivers that use the macros WR(q), RD(q), OTHERQ(q) or SAMESTR(q) from strsubr.h need to be rebuilt using ddi.h.
The PDA Synchronization (PDASync) application synchronizes the data from Sun applications such as Desktop Calendar, Desktop Mail, Memo, and Address, with data in similar applications on a user's personal digital assistant (PDA). The PDASync software may be accessed from the Application Manager or by entering /usr/dt/bin/sdtpdasync at the command line. Note that the serial port on SPARC platforms is a female DB-25 connector, so an adapter is necessary. For more information, refer to the Solaris Common Desktop Environment: User's Guide in the Solaris 8 User Collection.
The Hot Key Editor enables users to automate repetitive tasks, such as running executables or CDE actions, by predefining a series of commands to a given function key. The Hot Key Editor may be started from the Application Manager, the front panel, or the command line (sdthotkey). For more information, refer to the Solaris Common Desktop Environment: User's Guide in the Solaris 8 User Collection.
The Java Media Framework (JMF), a Java-based application, provides smooth streaming video file format support for MPEG-1, MPEG-2, Quicktime, and AVI, as well as audio support for MIDI. This feature enables users to take advantage of the real-time video creation and broadcast functionality.
The Java Media Player may be launched from the Applications menu or from the command line (sdtjmplay). For more information, see the Solaris Common Desktop Environment: User's Guide in the Solaris 8 User Collection and http://java.sun.com/products/java-media/jmf/index.html.
The audio mixer driver now enables multiple applications to play and record audio simultaneously. As an example, a user may listen to an audio CD and simultaneously play audio files from the web or receive audible notifications of some events such as email. This enhancement supersedes the previous capability, which only supported a single play application and a single record application.
The audio mixing function is turned on by default. It can be turned off as well as on using the new mixerctl(1) utility, or through other methods described in the audiocs(7D) man page.
In addition, CDE 1.4 now includes a new GUI tool, sdtaudiocontrol, that supersedes audiocontrol. The new sdtaudiocontrol uses the features of the audio mixer and provides:
For more information, see the audiocs(7D), audio_support(7I), mixer(7I) man pages and the Solaris Common Desktop Environment: User's Guide in the Solaris 8 User Collection.
The SDTImage screen snapshot feature now enables users to easily and quickly capture a screenshot image from the command line. The new synopsis for sdtimage(1) is as follows:
sdtimage [ -usage ] [ -v ] [ -verbose ] [ -timeout seconds ] [ -tooltalk ] [ -linear ] [ -snapshot [ -region [ WxH+X+Y ] | -screen | -window [ id | class ] ] ] [ -out output [ -f ] [ -outType imagetype ] ] [ input [ -inType imageType ] ]
The new command line options are as follows:
-tooltalk |
Execute in tooltalk mode. |
-linear |
Use a linear visual that corrects for non-linear characteristics of the monitor. |
-snapshot |
Request snapshot functionality to capture an area of the screen. The area of the screen can be specified in one of three ways: a region, a window, or the whole screen. If no option is specified, then the snapshot dialog will be displayed when the sdtimage GUI is presented. |
-out |
Output file to be saved. Use -f to force overwriting of an existing file when saving. |
-outType and -inType |
May be used to specify the image type: RASTER, TIFF, GIF, PS, EPSF, JPEG, XPM, and AUTO. |
Refer to the man pages for more details.
The Solaris Smart Card feature implements the Open Card Framework (OCF) 1.1 standard. Two external readers are supported: the Sun Smart Card Reader I and the iButton Reader. Three Smart Cards are supported: the Java-based iButton and Cyberflex cards, and the Payflex Smart Cards. The Solaris Smart Cards GUI may be accessed from the Application Manager or by entering /usr/dt/bin/sdtsmartcardadmin on the command line as superuser. In addition to the GUI, the following command line interfaces may be used to administer Solaris Smart Cards.
smartcard(1M) |
A command line interface to configure and administer a Smart Card |
ocfserv(1M) |
A per-host daemon that acts as the central point of communications with all Smart Cards connected to the host |
smartcard(5) |
An overview of Smart Card features on Solaris |
pam_smartcard(5) |
PAM authentication module for Smart Card |
ocf_escr1(7D) |
Sun external serial Smart Card terminal driver |
ocf_iscr1(7D) |
I2C Smart Card terminal driver |
ocf_ibutton(7D) |
iButton Smart Card terminal driver |
For more information on OCF, see http://www.opencard.org. For more information about Solaris Smart Cards, refer to the Solaris Smart Cards Administration Guide in the Solaris 8 Document Collection.
This new and enhanced version of XServer includes key features that increase user productivity and mobility. These new features include:
These features were first available in the Solaris 7 11/99 release.
Refer to the following man pages for more details:
xserver(1) |
X Window System display server. New commands for Xinerama, X Keyboard Extension (XKB). |
xset(1) |
User preference utility for X. New commands for Display Power Management Signaling (DPMS), Frame Buffer Power Management (FBPM). |
xfwp(1) |
X firewall proxy. |
lbxproxy(1) |
Low bandwidth X proxy. |
proxymngr(1) |
Proxy manager service. |
xrx(1) |
RX helper program. |
libxrx(1) |
RX Netscape Navigator Plug-in. |
rstart(1) |
A sample implementation of a Remote Start client. |
rstartd(1) |
A sample implementation of a Remote Start rsh helper. |
xkbcomp(1) |
Compile XKB keyboard description. |
xkbbell(1) |
XKB extension user utility. |
xkbwatch(1) |
XKB extension user utility. |
xkbvleds(1) |
XKB extension user utility. |
xkbprint(1) |
Print an XKB keyboard description. |
xevi(3X11) |
X Extended Visual Information functions. |
xfindproxy(1) |
Locate proxy services. |
xprt(1) |
Solaris print server for X Version 11 Release 6.4. |
devfsadm)The devfsadm command provides an improved mechanism for managing the special device files in the /dev and /devices directories, including support for dynamic reconfiguration events.
In previous Solaris releases, device configuration was handled by drvconfig, which managed the physical device entries in the/devices directory, and five link generators (devlinks, disks, tapes, ports, and aulinks), which managed the logical device entries in the /dev directory. For compatibility purposes, drvconfig and the other link generators are maintained as symbolic links to the devfsadm utility.
For more information, see the devfsadm(1M) man page.
The Solaris 8 operating environment provides a new automatic device Power Management framework. A device driver using the new interfaces will be automatically power managed on the appropriate platforms. Refer to the following man pages (especially pm-components(9P)) to find out about changes introduced in Solaris 8. Interfaces that have been marked obsolete are still supported in Solaris 8 but will be removed in a subsequent release. Therefore, using the new interfaces is strongly recommended. For more information, see Writing Device Drivers in the Solaris 8 Software Developer Collection.
attach(9E) |
The DDI_PM_RESUME command is obsolete for new drivers (those that export the pm-components property). Driver code should account for the possibility that the corresponding device may not be powered on at attach time. |
detach(9E) |
The DDI_PM_SUSPEND command is obsolete for new drivers (those that export the pm-components property). Drivers are expected to leave devices powered down upon detach. |
ddi_dev_is_needed(9F) |
This interface is obsolete. Use pm_raise_power(9F) instead. |
pm-components(9P) |
The Power Management (pm) driver provides an interface for applications to configure devices within the system for Power Management. The interface is provided through ioctl(2) commands. The pm driver may be accessed using /dev/pm. |
pm(7D) |
The Power Management (pm) driver provides an interface for applications to configure devices within the system for Power Management. The interface is provided through ioctl(2) commands. The pm driver may be accessed using /dev/pm. |
pm_create_components(9F) |
This interface is obsolete. It is replaced by the pm-components property. |
pm_destroy_components(9F) |
This interface is obsolete. |
pm_get_normal_power(9F) |
This interface is obsolete. |
pm_set_normal_power(9F) |
This interface is obsolete. |
pm_raise_power(9F)pm_lower_power(9F) |
These new functions replace ddi_dev_is_needed. pm_lower_power allows a driver to lower the power level of a component (which ddi_dev_is_needed did not), but it may only be called by a driver that is detaching. pm_raise_power allows a driver to raise the power level of a component. |
pm_power_has_changed(9F) |
This new interface allows the device driver to notify the power management framework if device hardware changes power level on its own. |
power(9E) |
The new power management model is documented and the old one made obsolete. |
power.conf(4) |
A new section is added describing automatic power management of devices, and entries that can be used to override the system defaults for these devices. The old "device power management" section is made obsolete. |
pci_report_pmcap(9F) |
A new interface for PCI devices to notify the PM framework what their minimum PCI clock speed is (in real time). |
pm_trans_check(9F) |
A new interface for device drivers to check if it is advisable to power cycle the device at this time. Currently, the check can be made for SCSI disk drives only. |
Sun Cluster introduces four new device classes. These new classifications are based on the extended behavior of the devices in a Sun Cluster environment.
ENUMERATED_DEV) - Physical devices with a one-to-one correspondence between a particular device node and a host where that device node is present.
NODESPECIFIC_DEV) - Devices that report particular information about the host where the device node is opened.
GLOBAL_DEV) - Node invariant pseudo devices such as /dev/ip.
NODEBOUND_DEV) - Pseudo device that maintains a cluster-wide state.
ddi_create_minor_node(9F) sets up a driver and prepares it for use. It accepts a flag as its last argument. For device drivers intended for use in a clustered environment, the flag must specify a device node class of GLOBAL_DEV, NODEBOUND_DEV, NODESPECIFIC_DEV, or ENUMERATED_DEV.
ddi_getiminor(9F) is a new interface that is used to translate between user-visible device numbers and in-kernel device numbers.
The generic SCSI device driver, sgen(7D), exports the uscsi(7I) interfaces to user processes. The sgen driver can be configured to bind to SCSI devices for which no system driver is available. Examples of such devices include SCSI scanners and SCSI processor devices. The sgen driver is configured using the /kernel/drv/sgen.conf file.
In the following example, sgen is configured to bind to all scanner and OCRW devices in the system, as well as the UltraToast4000 from ACME, and the PowerToast series of devices, regardless of vendor:
device-type-config-list="scanner", "ocrw";
inquiry-config-list= "ACME", "UltraToast 4000", "*", "PowerToast";
The target/lun pair is specified by uncommenting the appropriate line in sgen.conf. For example, a scanner at target 4 would be specified with the line:
name= "sgen" class= "scsi" target=4 lun=0;
The device file name has the format /dev/scsi/<devtype>cntndn where cn is the controller number, tn is the SCSI target ID and dn is the SCSI LUN. If the scanner in the example above was connected to controller c0, then the device file name would be used as follows:
int fildes = open("/dev/scsi/scanner/c0t4d0", O_RDWR);
The sgen driver supports two ioctl requests in addition to the one provided by uscsi(7I). The request to send a TEST UNIT READY command accepts no arguments:
#include <sys/scsi/targets/sgendef.h>
ioctl(fildes, SGEN_IOC_READY);
The request to change the level of diagnostics reporting accepts a single integer argument. For example, detailed output may be set by using:
ioctl(fildes, SGEN_IOC_DIAG, 3);
The USCSICMD request supported by the uscsi driver accepts a pointer to a uscsi_cmd structure:
#include <sys/scsi/impl/uscsi.h>
struct uscsi_cmd cmd;
/* set up cmd */
ioctl(fildes, USCSICMD, &cmd);
For more information, refer to the sgen(7D) and uscsi(7I) man pages. Make sure you understand the issues discussed in the SECURITY AND DATA INTEGRITY section before using sgen.
For an example of a scanner API, refer to the Scanner Access Now Easy (SANE) home page at http://www.mostang.com/sane.
The existing Sun WorkShop Compilers will work under Solaris 8. To determine if existing binaries will run on Solaris 8, refer to the section Binary Compatibility in this white paper. If you plan to upgrade your compilers while moving to Solaris 8, the upgrades should be taken in two separate steps. First, install the new compiler on your existing system and work out any code compatibility issues. Then, upgrade to Solaris 8 and work out any operating system issues. This two-step approach will help you to avoid trying to solve too many problems all at once. The features of various releases of the Sun WorkShop C/C++ Compilers are listed below for reference.
_Restrict) as an extension
-errchk, -fprecision, -xlic_lib, -xcrossfile
typeid)
dynamic_cast
rwtools7)
ild)
-xarch, -xcode, -xprefetch
error_messages
-errchk=sizematch
boolnew and array delete
-compat, -xcode=a, -xhelp=flags, -xhelp=readme, -xnolibmil, -xprefetch
-compat.
-compat=4 for compatibility with 4.0.1, 4.1, and 4.2 compilers. Use -compat=5 for 5.0 compiler compatibility.
This section gives an overview of new features and updates that are documented in the Linker and Libraries Guide of the Solaris 8 Document Collection.
/usr/lib/secure for 32-bit objects and /usr/lib/secure/sparcv9 for 64-bit SPARC objects.
-z nodefaultlib option, and runtime configuration files created by the new utility crle(1).
extern mapfile directive provides for -z defs usage with externally defined symbols.
$ISALIST, $OSNAME, and $OSREL dynamic string tokens.
-Bsymbolic option are provided.
-p and -P. Additional runtime link auditing interfaces la_activity() and la_objsearch() have been added.
DT_CHECKSUM.
/usr/lib/sparcv9, the environment variable LD_LIBRARY_PATH_64, and the runtime linker /usr/lib/sparcv9/ld.so.1.
-z combreloc option.
$ORIGIN dynamic string token.
SHT_SUNW_COMDAT section has been added to allow for the elimination of symbols defined more than once.
SHT_SUNW_move section has been added to allow for partially initialized symbols.
la_symbind64(), la_sparcv9_pltenter(), and la_pltexit64(), together with a new link-auditing flag LA_SYMB_ALTVALUE, have been added.
-z weakextract option. Extracting all archive members can be achieved using the -z allextract option.
-z ignore option.
_START_ and _END_ to provide a means of establishing an object's address range.
dlopen(3DL).
dlsym(3DL) handle RTLD_DEFAULT.
mapfile file control directive $ADDVERS.
SHN_BEFORE, SHN_AFTER, SHF_ORDERED, and SHF_EXCLUDE.
DT_1_FLAGS, is supported.
strerror<(3C).
This section describes the new features in the Solaris 8 operating environment that are useful for debugging and troubleshooting.
coreadm CommandThe coreadm command provides flexible core file naming conventions and better core file retention. You can use the coreadm command, for example, to configure a system in which all process core files are placed in a single directory. Core files in a specific directory can then be examined whenever a Solaris process or daemon terminates abnormally. See the man page coreadm(1M).
proc ToolsSome of the proc tools have been enhanced to examine process core files as well as live processes. The proc tools are utilities that can manipulate features of the /proc file system.
The pstack, pmap, pldd, pflags, and pcred tools can now be applied to core files by specifying the name of the core file on the command line, similar to the way you specify a process ID to these commands. For more information on using proc tools to examine core files, see the man page proc(1).
The boot and system error message format now provides a numeric identifier, module name, and time stamp to messages generated by the syslogd(1M) logging facility. In addition, messages that were previously lost after a system panic and reboot are now saved.
Each message will be preceded by an identifier in the format: [ID msgid facility.priority]; for example, [ID 123456 kern.notice].
The msgid field is the message's numeric identifier as described in the msgid(1M) man page. The facility and priority fields are as described in syslog.conf(4). Message IDs appear in/var/adm/messages but are not displayed on the console so as to reduce visual clutter. If the message originated in the kernel, the kernel module's name is used instead of just "unix:".
This feature does not require any driver changes. Message ID generation is enabled by default in Solaris 8. However, if an existing application uses /var/adm/message and cannot handle the additional message ID field, defining the msgid=0 property in the log.conf file will disable message ID generation as described in the log(7D) man page.
The Modular Debugger (MDB) is a new general purpose debugging tool for Solaris. Its most notable feature is its extensibility. The dynamic module facility allows programmers to implement their own debugging commands to perform program-specific analysis. MDB currently provides support for the following types of targets:
/dev/kmem and /dev/ksyms)
MDB provides a host of usability features, including:
For more information, refer to the Solaris Modular Debugger Guide in the Solaris 8 Software Developer Collection and the mdb(1) man page.
The consadm command allows the system administrator to select a serial device to be used as an auxiliary console. This allows a modem to be connected for troubleshooting remote system problems. The remote console may be used to monitor console messages and participate in init state transitions. For more information, see the consadm(1M) man page and the System Administration Guide, Volume 2 in the Solaris 8 Document Collection.
The apptrace utility enables application and system level debugging by tracing calls directly from an executable object to the shared libraries it depends upon. Call-tracing enabled by apptrace is more reliable than the previously available sotruss command. See the apptrace(1) man page.
The iostat utility iteratively reports terminal, disk, and tape I/O activity, as well as CPU utilization.
The following iostat enhancements were added in Solaris 2.6:
-e Display device error summary statistics. The total errors, hard errors, soft errors, and transport errors are displayed.
-E Display all device error statistics.
-M Display data throughput in MB/sec instead of KB/sec.
-n Display names in descriptive format (for example, cXtYdZ, rmt/N, server:/export/path).
-p For each disk, report per-partition statistics in addition to per-device statistics.
-P For each disk, report per-partition statistics only, no per-device statistics.
st driver.
sd(7D), ssd(7D) and st(7D) man pages.
The following iostat enhancements are included in Solaris 8:
State change message has been replaced with a more detailed message that describes what actually happened (for example, device_name added/removed, NFS_filesystem mounted/unmounted, cpu offline/online).
-C When the -n and -x options are also selected, report extended disk statistics aggregated by controller id.
-m Report file system mount points.
-r Emit data in a comma-separated format.
-s Suppress messages related to "state changes".
-T Emit a time stamp.
-z Don't print lines whose underlying data values are all zeroes.
Refer to the iostat(1M) man page for more details.
Starting in Solaris 2.6, online documentation could be accessed with any popular browser. The AnswerBook2 viewer provided a web browser-based interface that enabled users to view and print a variety of Solaris information, including existing AnswerBook documents and man pages.
In Solaris 7, man pages were available in AnswerBook2 (SGML), rather than AnswerBook format. This provided improvements in navigation and links to man pages directly from other AnswerBook2 documents. Accompanying this change was a new man utility that can display man pages coded with SGML as well as the traditional nroff.
The UltraSPARC and Pentium microprocessor families contain hardware performance counters that allow the measurement of many different hardware events related to CPU behavior, including instruction and data cache misses as well as various internal states of the processor. More recent processors allow a variety of events to be captured. The counters can be configured to count user events or system events, or both. The two processor families currently share the restriction that only two event types can be measured simultaneously.
Solaris 8 introduces two new commands that use CPU performance counters. The cpustat(1M) utility allows CPU performance counters to be used to monitor the overall behavior of the CPUs in the system. The cputrack(1) utility allows CPU performance counters to be used to monitor the behavior of a process or family of processes running on the system.
Developers can create their own monitoring tools by using the following library APIs:
cpc(3CPC) |
Hardware performance counters |
cpc_version(3CPC) |
Check the version the application was compiled with against the version of the library |
cpc_getcpuver(3CPC) |
Determine the performance counter version of the current CPU |
cpc_getcciname(3CPC) |
Return the corresponding printable string to describe that interface |
cpc_getnpic(3CPC) |
Return the number of valid counter registers in the cpc_event(3CPC) data structure |
cpc_getcpuref(3CPC) |
Return a reference to the corresponding processor documentation |
cpc_access(3CPC) |
Test access CPU performance counters |
cpc_bind_event(3CPC) |
Use CPU performance counters on lwps |
cpc_count_usr_events(3CPC) |
Enable and disable performance counters |
cpc_pctx_bind_event(3CPC) |
Access CPU performance counters in other processes |
cpc_event(3CPC) |
Data structure to describe CPU performance counters |
cpc_event_diff(3CPC) |
Simple difference and accumulate operations |
cpc_seterrfn(3CPC) |
Control libcpc error reporting |
cpc_shared_open(3CPC) |
Use CPU performance counters on processors |
cpc_strtoevent(3CPC) |
Translate strings to and from events |
pctx_capture(3CPC) |
Process context library |
pctx_set_events(3CPC) |
Associate callbacks with process events |
Note that cpustat, cputrack, libcpc, and libpctx are all classified as evolving.
Perl 5.005_03 is included in the Solaris 8 release. The binary files are located in /usr/perl5/bin. To access the Perl 5 man pages, add /usr/perl5/man to your MANPATH environment variable. See the man page perl(1) for general Perl information. See the section Application Environment Compatibility of this white paper for compatibility issues.
At the time of this writing, version 5.005_03 is the latest stable version for production release. The experimental developer's release is at version 5.005_62. For the latest information on Perl, go to http://www.perl.org.
Role-based access control (RBAC) gives developers the opportunity to deliver fine-grained security in new and modified applications. RBAC is an alternative to the all-or-nothing security model of traditional superuser-based systems. With RBAC, an administrator can assign privileged functions to specific user accounts (or special accounts called roles). The System Administration Guide, Volume 2 in the Solaris 8 Document Collection refers to the following tools:
auths(1) |
Display authorizations for a user |
makedbm(1M) |
Make a dbm file |
nscd(1M) |
Name a service cache daemon; useful for caching the user_attr, prof_attr, and exec_attr databases |
pam_roles(5) |
Role account management module for PAM; checks for the authorization to assume role |
pfexec(1) |
Used by profile shells to execute commands with attributes specified in the exec_attr database |
profiles(1) |
Display profiles for a specified user |
roles(1) |
Display roles granted to a user |
roleadd(1M) |
Add a role account on the system |
roledel(1M) |
Delete a role's account from the system |
rolemod(1M) |
Modify a role's account information on the system |
useradd(1M) |
Add a user account on the system. The -P option assigns a role to a user's account |
userdel(1M) |
Delete a user's login from the system |
usermod(1M) |
Modify a user's account information on the system |
auth_attr(4) |
Authorization description database |
exec_attr(4) |
Execution profiles database |
prof_attr(4) |
Profile description database |
user_attr(4) |
Extended user attributes database |
policy.conf(4) |
Configuration file for security policy; lists granted authorizations |
New applications may be written that check for authorizations instead of checking for specific IDs such as superuser. The rbac(5) man page describes how the chkauthattr(3SECDB) library function may be used for such applications. Additional interface functions may be found in the following man pages:
kva_match(3SECDB) |
Look up a key in a key-value array |
getauthattr(3SECDB) |
Get authorization entry |
getexecattr(3SECDB) |
Get execution profile entry |
getprofattr(3SECDB) |
Get profile description and attributes |
getuserattr(3SECDB) |
Get user_attr entry |
getauusernam(3BSM) |
Get audit_user entry |
libsecdb(3LIB) |
Security Attributes Database library |
libthreadThe standard Solaris thread implementation is a two-level model, in which user-level threads are multiplexed over possibly fewer lightweight processes (LWPs). Solaris 8 software provides an alternate threads implementation, a one-level model, in which user-level threads are associated one-to-one with LWPs.
The standard two-level model is efficient in its use of kernel resources. A smaller number of LWPs will consume less physical memory and will require less interaction with the kernel. The alternate one-level model gains some efficiency due to its simplicity. However, it consumes more operating system memory for LWPs and requires more interaction with the kernel.
Choosing between the two models depends on the characteristics of the application. Some applications may perform better with the standard two-level model while others may perform better with the alternate one-level model. If the standard implementation provides sufficient performance, then no further effort is required to make the decision. Otherwise, the software developer should run benchmarks with each model to decide which one to use. The interfaces provided are exactly the same for both implementations, so no changes to the application source code are needed.
To use the alternate implementation, link with libraries in/usr/lib/lwp or /usr/lib/lwp/64. For multithreaded applications that have been previously linked, the LD_LIBRARY_PATH or LD_LIBRARY_PATH_64 environment variables may be used. Refer to the alternate implementation section of the threads(3THR) man page for a more detailed description.
The 8-bit visual shared library provides a set of translation functions, enabling 8-bit visual applications to run on hardware that only provides support for 24-bit visual depth. An example of such hardware is the Sun Ray 1. The shared library may be found in /usr/openwin/server/lib/libsv8.so, which is linked to libsv8.so.1.
An OpenWindows server uses a DDX interface to access the device DDX handler. The device DDX handler in turn uses regular X provided shared libraries (for example, libmi, libcfb, libmfb) and Sun extended shared libraries (for example, libovl, libdga, libmpg, libmhc). The new libsv8 is an additional Sun extended shared library to be used by the device DDX handler.
The following selection of freeware is included in the Solaris 8 release, which will save the time needed to download and install these common utilities.
bash(1) |
GNU Bourne-Again SHell (2.03) |
bzip2(1), bunzip2(1) |
A block-sorting file compressor (0.9.0c |
bzcat(1) |
Decompresses files to stdout |
bzip2recover(1) |
Recovers data from damaged bzip2 files |
gzip(1), gunzip(1), gzcat(1) |
Compress or expand files (1.2.4) |
gpatch(1) |
Apply a diff file to an original (2.5.4) |
libz(3), zlib(3) |
Compression/decompression library (1.1.3) |
less(1) |
Similar to more but provides the ability to go backward in a file (340) |
tcsh(1) |
C shell with file name completion and command line editing (6.09) |
mkisofs(1M) |
Create an ISO9660 file system with optional Rock Ridge attributes (1.12b5) |
rpm2cpio(1) |
An rpm->cpio converter |
zip(1),
zipcloak(1),
zipnote(1),
zipsplit(1) |
Package and compress (archive) files (2.2) |
zsh(1) |
The Z shell (3.0) |
Sources are available in separate packages on the OS CD. The sources are not installed by default.
The following sections describe ongoing support for 64-bit addressing in Solaris 8, the advantages 64-bit applications have over 32-bit applications, and what applications should be ported to the 64-bit environment.
It also explains the changes in the 64-bit data model, discusses binary compatibility issues, gives a brief outline of rules to be followed when porting applications to a 64-bit environment, and provides some useful tools to determine potential 64-bit problems.
64-bit addressing was developed to support database applications that store huge amounts of information. A 64-bit application can also serve a large number of simultaneous users.
A bit is the smallest unit of data operated on by computers. Eight bits make up a byte, which can represent 256 values. A word, a specified number of bytes, is the unit of data handled by a CPU. 32-bit processors use 32-bit words and 64-bit processors use 64-bit words. 64-bit data can be easily represented on a 32-bit processor; it is very difficult to represent an effective 64-bit address with a word size limit of 32 bits. With 64-bit words, the address space is vastly increased.
Most applications developed today do not even come close to reaching the limits of 32-bit address space, but applications that work with large amounts of data are reaching and beginning to exceed these limits. Without 64-bit address space, these applications would be prohibitively slow and could not serve as many simultaneous users.
Taking advantage of 64-bit address space requires a huge amount of physical memory. Otherwise, virtual paging will defeat the purpose of 64-bits.
When considering such resources, balance must be achieved between physical memory, CPU speed, and I/O bandwidth.
Use of 64-bit address space advantage on multiple processors, where applications are multithreaded, enables each process to grow more, reducing the need to page and improving performance dramatically.
There are two Solaris C data type models. The 32-bit version is referred to as ILP32 (ints, longs, and pointers are 32-bit) and the 64-bit version as LP64 (longs and pointers are 64-bit).
The 32-bit (ILP32) data model and 64-bit (LP64) data model are described in the following table.
| C data type | ILP32 (in bits) | LP64 (in bits) |
char |
8 | 8 |
short |
16 | 16 |
int |
32 | 32 |
long |
32* | 64* |
Long long |
64 | 64 |
pointer |
32* | 64* |
enum |
32 | 32 |
float |
32 | 32 |
double |
64 | 64 |
long double |
128 | 128 |
As shown above, in the 64-bit model (LP64), only long and pointer data types changed to 64-bit. All other fundamental types remain as they were in the 32-bit model (ILP32).
Few applications require conversion. Most applications can remain as 32-bit applications and still run on a 64-bit operating system without requiring any code changes or recompilations.
Applications that warrant conversion are those that:
libkvm, /dev/mem or /dev/kmem
/proc to debug 64-bit processes
The 32-bit APIs supported in the 64-bit environment are the same as the APIs supported in the 32-bit environment. However, some applications might need to be recompiled as 64-bit applications.
To aid developers in building stable Solaris applications, the Solaris ABI Program has produced two tools that determine if an application is using only the correct Solaris interfaces, and that it is using them correctly.
The first tool, appcert, is a Perl script that statistically examines ELF (executables and shared objects) to determine what Solaris library interfaces they use. This identifies which binaries use problematic interfaces and which do not.
The second tool, apptrace is a C program that takes advantage of the link- auditing functionality introduced in the Solaris 2.6 run-time linker. It dynamically audits calls to Solaris library routines that have changed in Solaris 8, and warns of possible breakage.
These two tools are described in the section How to Check your Application for Compatibility Issues in this white paper.
Existing 32-bit SPARC applications are binary compatible and can run on either the 32-bit or 64-bit operating system environments. The only exceptions are those that deal with kernel memory or /proc.
Source level compatibility has been maintained for 32-bit applications. For 64-bit applications, the principal changes pertain to data types used in the APIs. 32-bit applications that use these data types and interfaces correctly are source compatible and will make the transition to 64-bit more easily. Definitions of data types can be found in sys/types.h and inttypes.h files.
Because 32-bit drivers cannot be used with the 64-bit operating system, at a minimum, these drivers must be recompiled. Moreover, the 64-bit drivers need to support both 32-bit and 64-bit applications. All the drivers supplied with the 64-bit operating system environment support both 32-bit and 64-bit applications.
Following are some of the data types available. Using these data types, instead of such types as "int" or "long" will make the migration to 64-bit easier.
sys/types.hTypes clock_t, dev_t, off_t, ptrdiff_t, size_t, ssize_t, and time_t:
inttypes.h
int8_t, int16_t, int32_t, int64_t, uint_t, uint16_t,...
int_least8_t,...int_least64_t, uint_least8_t,...uint_least64_t
intptr_t and uintptr_t require only definition to change when different data model is used, hence should be used instead of long or unsigned long.
INT8_MIN,...INT64_MAX,...
A single set of system headers supports both 32-bit and 64-bit compilation environments. These can be found in sys/isa_defs.h. Inclusion of sys/types.h automatically includes the sys/isa_defs.h file. The following symbols are defined by the compilation environment:
__sparc |
Indicates any of the SPARC family of processor architectures, including SPARC V7, SPARC V8, and SPARC V9. |
__sparcv8 |
Indicates the 32-bit SPARC V8 architecture |
__sparcv9 |
Indicates the 64_bit SPARC V9 architecture |
__i386 |
Generic for all processors implementing the Intel 386 instruction set or a superset of it |
Note: The symbols __sparcv8 and __sparcv9 are mutually exclusive and are relevant only when the symbol __sparc is defined.
_ILP32 |
The data model where sizes of int, long and pointer are both 32 bits |
_LP64 |
The data model where sizes of long and pointer are both 64 bits |
-v).
lint(1B) (cannot detect all problems).
-errchk=longptr64 option to generate LP64 warnings.
-D__sparcv9 option.
appcert and apptrace.
Lint Warning) Do not assume that an int and a pointer are the same size. In the ILP32 environment, a lot of code relies on the assumption that ints and pointers are the same size. For example, pointers are often cast to int or unsigned int for address arithmetic. Instead, pointers should be cast to long because long and pointer are the same size in both the ILP32 and LP64 worlds.
char *p; p = (char *) ((int)p & PAGEOFFSET); %warning: conversion of pointer loses bits
char *p; p = (char *) ((uintptr_t)p & PAGEOFFSET);
int and long Data Type Sizes Because int and long were not distinguished in ILP32, a lot of existing code uses them indiscriminately, assuming that they are interchangeable. Any code that makes this assumption must be modified to work for both ILP32 and LP64.
Sign extension is a common problem when converting to 64-bit. To fix sign extension problems, use explicit casting. When compiled as a 64-bit program, the addr variable in the following example becomes sign extended, even though both addr and a.base are unsigned types.
struct foo {
unsigned int base:19, rehash:13; };
main(int argc, char *argv[]) {
struct foo a;
unsigned long addr;
a.base = 0x40000;
addr = a.base << 13; /*sign extension here*/
printf("addr 0x%lx\n", addr);
addr = (unsigend int)(a.base << 13); /*no sign extension here*/
printf("addr 0x%lx\n". addr);
}
Lint Warning) In general, using pointer arithmetic is preferable to using address arithmetic because pointer arithmetic is independent of the data model, whereas address arithmetic may not be.
int *end; int *p; p = malloc(4 * NUM_ELEMENTS); end = (int *)((unsigned int)p + 4 * NUM_ELEMENTS); %warning: conversion pointer loses bits
int *end; int *p;
p = malloc(sizeof(*p) * NUM_ELEMENTS);
end = p + NUM_ELEMENTS;
Internal data structures in applications should be checked for holes. In the 64-bit environment on SPARC platforms, all types of structures are aligned to at least the size of the largest quantity within them. A simple rule for packing the structure is to move long and pointer fields to the beginning of the structure.
Be sure to check unions because their fields might have changed.
Use casts to specify the type of a numeric constant.
int i = 32; long j = 1L <<32 /* j will get zero if 1 specified instead of 1L */ >
The C compiler assumes a type int for any function or variable that is used in a module and not defined or declared externally. Any longs or pointers used in this way are truncated by the compiler's implicit int declaration.
The appropriate extern declaration for function should be placed in the header and not in the C module.
sizeof() is an Unsigned Long In LP64, sizeof() has the effective type of an unsigned long. Occasionally sizeof() is passed to a function expecting an argument of type int, or assigned or cast to an int. In some cases, this truncation may cause loss of data.
Format strings for printf(3S), sprintf(3S), scanf(3S), and sscanf(3S) might need to be changed for long and pointer arguments.
For pointer arguments, the conversion operation given in the format string should be %p to work in both 32-bit and 64-bit environment.
#ifdef for Explicit 32-bit Versus 64-bit PrototypeIn the header, these should be distinguishable by the use of _LP64 or _ILP32 feature test macros.
Because 32-bit device drivers cannot be used with the 64-bit operating system, at a minimum, these drivers must be recompiled. Moreover, the 64-bit drivers need to support both 32-bit and 64-bit applications. All the drivers supplied with the 64-bit operating system environment support both 32-bit and 64-bit applications.
The following sections briefly discuss code specific and driver specific issues.
Before converting a device driver for the 64-bit environment, it is useful to understand how it differs from the 32-bit environment. The current 32-bit Solaris C language data model, called ILP32, defines ints, longs, and pointers as 32-bits, shorts as 16 and chars as 8 bits. The C data type model chosen for the 64-bit operating system is LP64, which defines longs and pointers as 64-bits. In addition to the data model changes, some system-derived types, such as size_t, have been expanded to 64-bit quantities when compiled in the 64-bit environment.
There are several potential problems caused by the changes in size of longs and pointers. Source code that assumes that int, long and pointer types are the same size will be incorrect for 64-bit Solaris. There could be some cast types that may need to be updated, since the underlying data types may have changed. Data structures containing long and pointers need to be checked for different offset values.
In addition to general code cleanup to support the data model changes, there are several driver-specific issues to consider.
In the 64-bit environment, new common access functions that use fixed-width data types have been provided so that drivers can clearly specify the size of the data they are requesting. Drivers that use old common access routines such as ddi_getw() need to be changed.
A driver may need to be updated to support data sharing between 64-bit drivers and 32-bit applications. The ioctl(9E), devmap(9E), and mmap(9E) entry points must be written so that the driver can determine whether the data model of the application is the same as that of the kernel. This usually means converting a 64-bit driver structure to fit in a 32-bit application structure.
The Solaris 8 operating environment provides more deterministic response times for real time processes by ensuring that STREAMS processing uses a priority that does not conflict with user process priority. In addition, the following new fields have been added to the queue_t data structure defined in streams.h:
size_t q_mblkcnt; /* mblk counter for runaway msgs */ struct msgb *q_sqhead; /* first syncq message */ struct msgb *q_sqtail; /* last syncq message */ boolean_t q_sqqueued; /* messages queued for syncq */ /* Protected by SQLOCK */ size_t q_sqcount; /* bytes on syncq */ /* Probabaly could use q_syncqmsgs, */ struct queue *q_sqnext; /* Next Q on syncq list */ struct queue *q_sqprev; /* Previous Q on syncq list */ pri_t q_spri; /* Scheduling priority */
Any driver or module that uses the following macros (listed in sys/strsubr.h) should be recompiled.
WR(queue_t) RD(queue_t) OTHERQ(queue_t) SAMESTER(queue_t)
If you upgrade to Solaris 8 from Solaris 2.6 or earlier, you also get those features that were introduced with Solaris 7.
In some cases, a time-critical application may need to run on a dedicated CPU in a multiprocessor system. However, interrupting devices can severely impact the performance of the time-critical application. Interrupt sheltering provides a solution to this case by removing the processor from interrupt participation. The following system call and maintenance commands have been modified to support interrupt sheltering.
p_online(2) |
Flag may be set to P_NOINTR for a processor |
psradm(1M) |
The -i option sets the specified processors to no-intr |
psrset(1M) |
The -f option disables interrupts for all processors within the specified set |
psrinfo(1M) |
Can display the no-intr state |
mount_ufs(1M) OptionTo ignore access time updates on files, you can specify the -o noatime option when mounting a UFS file system. This option reduces disk activity on file systems where access times are unimportant (for example, a Usenet spool). See also the dfratime and nodfratime options for deferring access time updates introduced in Solaris 8.
LDAP first appeared in Solaris 7 as a client library that enabled developers to write LDAP applications and also allowed users to run LDAP enabled applications. In Solaris 8, back-end support has been added to the name service switch for LDAP. Refer to the section Native LDAP of this white paper for more details.
pgrep(1) and pkill(1)Thes pgrep and pkill user commands find or signal processes by name and other attributes. They provide a simpler alternative to using combinations of ps, grep, egrep, awk, and kill. See the man pages for more details.
traceroute(1M)Solaris 7 software bundles the popular traceroute utility. The traceroute utility is used to trace the route an IP packet follows to an Internet host. It is especially useful for determining routing misconfiguration and routing path failures.
TCP selective acknowledgment (TCP SACK) provides the support described in RFC 2018 to solve the problems related to congestion and multiple packet drops, especially in applications using TCP large windows (RFC 1323) over satellite links or transcontinental links. The tcp(7P) man page describes using ndd to modify the configuration parameter tcp_sack_permitted.
Solaris 7 added NIS+ security based on the Generic Security Service Application Program Interface (RFC 2078). In addition to the original 192-bit Diffie-Hellman key length, 640- and 1024-bit Diffie-Hellman keys are available. The nisauthconf(1M) maintenance command is used to configure the type of Diffie-Hellman key. The nisaddcred(1M) maintenance command also supports the extended authentication types.
plimit(1)The plimit(1) user command is used to get or set the resource limits of running processes. It is not limited to the current process like limit(1) and ulimit(1) are. Refer to the man page for more details.
A number of new features are described in the Linker and Libraries Guide for Solaris 7. Two of the more prominent features are described below.
The runtime linker permits programs to find shared libraries without having to set LD_LIBRARY_PATH. Shared objects may be loaded at runtime relative to where the requesting object is located. Refer to the "Locating Associated Dependencies" and "Introducing $ORIGIN" sections of the Linker and Libraries Guide for more details.
Loading of shared libraries is more efficient. The loading of a shared object can be deferred until the object is actually referenced by the running program. Refer to the "Lazy Loading of Dynamic Dependencies" section of the Linker and Libraries Guide for more details.
truss(1) Options in Solaris 7The following are new truss options:
-d |
Includes a time stamp on each line of trace output |
-D |
Includes a time delta on each line of trace output |
-T |
System calls that stop the process |
-u |
User-level function call tracing |
-U |
User-level function calls that stop the process |
psrset(1M) Options in Solaris 7The following are new psrset options:
-e |
Executes a command in the specified processor set |
-f |
Disables interrupts for all processors within a processor set |
-n |
Enables interrupts for all processors with a processor set |
snoop(1M) ExtensionsSupport for the keywords bootp and dhcp has been added. This makes using snoop udp port 67 and snoop udp port 68 unnecessary.
Support for interpreting DNS protocol messages has been added.
Support for interpreting SOCKS protocol (RFC 1928) messages has been added.
Support for interpreting TCP window scale, timestamp, and SACK options has been added.
isainfo(1)The isainfo utility is used to identify various attributes of the instruction set architectures supported on the currently running system. Among the questions it can answer are whether 64-bit applications are supported, or whether the running kernel uses 32-bit or 64-bit device drivers.
Invoking isainfo on a 32-bit IA platform
example% isainfo -v 32-bit i386 applications
example% isainfo -k i386
Invoking isainfo on a system running the 32-bit operating system on a 64-bit SPARC processor.
example% isainfo -n sparc
example% isainfo -v 32-bit sparc applications
example% isainfo -kv 32-bit sparc kernel modules
Invoking isainfo on the same hardware platform (that is, a 64-bit SPARC processor) running the 64-bit operating system.
example% isainfo sparcv9 sparc
example% isainfo -n sparcv9
example% isainfo -v 64-bit sparcv9 applications 32-bit sparc applications
example% isainfo -vk 64-bit sparcv9 kernel modules
If you are upgrading to Solaris 8 from Solaris 2.5.1 or earlier, you will also get the features introduced with Solaris 2.6.
By default, the UNIX file system (UFS) performs caching and automatic read-ahead when it begins to detect a sequential access pattern. In applications that perform their own internal caching, such as database servers, this gives a "double caching" effect, which may degrade performance. The directio(3C) library function provides information to the system about bypassing the traditional caching mechanism on a per-file basis. The mount_ufs(1M) maintenance command controls the direct I/O configuration of an entire file system using the specific options forcedirectio and noforcedirectio.
TCP large windows provides the support described in RFC 1323. It improves performance over high-bandwidth networks such as ATM, or high-delay networks such as satellite links, by using windows that exceed the normal 64 Kbyte limit. The tcp(7P) man page describes three ways to turn on the window scale option:
SO_SNDBUF or SO_RCVBUF using setsockopt()
ndd(1M) to modify the configuration parameter tcp_wscale_always
Solaris 2.6 was the first release tested for year 2000 compliance. However, year 2000 related bugs were found after shipping and patches were made available. Solaris 7 had fewer year 2000 bugs and also required patches. Free patches to fix year 2000 related bugs for Solaris 2.3 through Solaris 7 may be obtained at
http://sunsolve.sun.com.
Scoping allows the developer of a shared library to control which symbols are local and which symbols are global. If the user of a shared library accesses a symbol that should be local, then future changes to the shared library that remove or redefine that symbol will make the shared library incompatible with the existing application. Restricting symbols to local will prevent this from happening. Making a symbol local is accomplished by creating a mapfile that is used with the link-editor's -M option.
The following example has str, bar and foo all as global.
$ cat foo.c
extern const char * bar();
const char * foo()
{
return (bar());
}
$ cat bar.c
const char * str = "returned from bar.c";
const char * bar()
{
return (str);
}
$ cc -o lib.so.1 -G foo.c bar.c
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[29] |0x000104d0|0x00000004|OBJT |GLOB |0x0 |12 |str
[32] |0x00000418|0x00000028|FUNC |GLOB |0x0 |6 |bar
[33] |0x000003f0|0x00000028|FUNC |GLOB |0x0 |6 |foo
The following example uses a mapfile to change bar and str to local.
$ cat mapfile
{
local:
bar;
str;
};
$ cc -o lib.so.1 -M mapfile -G foo.c bar.c
$ nm -x lib.so.1 | egrep "foo$|bar$|str$"
[27] |0x000003dc|0x00000028|FUNC |LOCL |0x0 |6 |bar
[28] |0x00010494|0x00000004|OBJT |LOCL |0x0 |12 |str
[33] |0x000003b4|0x00000028|FUNC |GLOB |0x0 |6 |foo
This symbol scope reduction has an additional performance advantage. The symbolic relocations against the symbols bar and str that would have been necessary at runtime are now reduced to relative relocations. This reduces the runtime overhead of initializing and processing the shared object. Refer to the Linker and Libraries Guide in the Solaris 8 Document Collection for more details on reducing symbol scope.
The Linker and Libraries Guide covers internal versioning and external versioning in detail. Compatible updates to a shared object can be accommodated by maintaining version definitions internal to the object being generated. Incompatible updates can be accommodated by producing a new external versioned name. Both of these versioning techniques allow for the selective binding of applications as well as verification of correct binding at runtime.
Internal versioning, like scoping, is controlled by a mapfile that is used with the link-editor's -M option. The following is a simple example of internal versioning.
$ cat foo.c
extern const char * _foo1;
void foo1()
{
(void) printf(_foo1);
}
$ cat data.c
const char * _foo1 = "string used by foo1()\n";
$ cat mapfile
SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
$ cc -o libfoo.so.1 -M mapfile -G foo.o data.o
$ nm -x libfoo.so.1 | grep "foo.$"
[33] |0x0001058c|0x00000004|OBJT |LOCL |0x0 |17 |_foo1
[35] |0x00000454|0x00000034|FUNC |GLOB |0x0 |9 |foo1
The first line in mapfile identifies the SUNW_1.1 internal version definition. The Linker and Libraries Guide provides additional examples that show how new version definitions may be added as the shared object evolves. When a dynamic executable or shared object is built against other shared objects, these dependencies are recorded in the resulting object as shown in the following example.
$ cat prog.c
extern void foo1();
extern void foo2();
main()
{
foo1();
foo2();
}
$ cc -o prog prog.c -L. -R. -lfoo
$ pvs -r prog
libfoo.so.1 (SUNW_1.2, SUNW_1.2.1);
In this example, the application prog has bound to the two interfaces SUNW_1.1 and SUNW_1.2. If a new global symbol foo2 is added in a subsequent version of the shared library, prog will not have any problems with a relocation error since the use of the earlier interface has been recorded.
The following utilities have been changed or added to support internal versioning.
New ld(1) options for mapfile syntax: -Blocal, -Breduce, -znoversion
New ldd(1) option: -v displays all dependency relationships and dependency version requirements
pvs(1) - display the internal version information of dynamic objects
External versioning is used when a shared object's interface changes in an incompatible manner such that it will break old applications. The different versions are commonly expressed as a file name suffixed with a version number as in the following example.
$ ls -l libfoo* lrwxrwxrwx 1 usr grp 11 1993 libfoo.so -> libfoo.so.3 -rwxrwxr-x 1 usr grp 3136 1991 libfoo.so.1 -rwxrwxr-x 1 usr grp 3237 1992 libfoo.so.2 -rwxrwxr-x 1 usr grp 3554 1993 libfoo.so.3
The older versions of the shared object, libfoo.so.1 and libfoo.so.2, are available to older applications and libfoo.so.3 offers the latest major release for building and running new applications.
The introduction of large file support in Solaris 2.6 allowed applications to access files greater than 2 gigabytes in size. To support the large files feature, the mount_ufs(1M) maintenance command has two new options: largefiles and nolargefiles. Large file support is enabled by default. Use the disable option with older applications that are not able to safely handle large files.
When porting an application to the large file environment, there are three types of source code modifications that may take place. These map directly to one of three desired operating modes:
No modifications to the makefiles are necessary.
Calls to open()/fopen(), lstat()/stat()/fstat(), lseek()/fseek(), and mmap() should handle EOVERFLOW or EFBIG errors appropriately.
Pass -D_FILE_OFFSET_BITS=64 to the compiler in your makefile.
ino_t, off_t, fpos_t, rlim_t, blkcnt_t, fsblkcnt_t, and fsfilcnt_t have been extended to include the 64-bit version.
The code should be examined for interfaces where return values and constants were not declared to be one of these types. For example,
long curpos; curpos = lseek(fd, 0L, SEEK_CUR);
should be changed to:
off_t curpos; curpos = lseek(fd, (off_t)0, SEEK_CUR);
Any variables used as counters or for temporary storage of sizes or offset information must be of the correct type to avoid truncation. For example,
int delta; long curpos; .... curpos = lseek(fd, 0L, SEEK_CUR); curpos += delta;
should be changed to:
off_t curpos; .... curpos = lseek(fd, (off_t)0, SEEK_CUR); curpos += delta;
Any output or in-memory formatting strings utilized in reference to the large file sizing entities must be converted. For example:
off_t offset;
printf(" %7ld", offset);
should be modified to:
off_t offset;
printf(" %7lld", offset);
Use the appropriate conversion routine when variables representing size or offset information are being converted from string values and vice-versa. For example:
off_t offset; #if _FILE_OFFSET_BITS - 0 == 64 offset = atoll(argv[1]); #else offset = atol(argv[1]); #endif
Pass -D_LARGEFILE64_SOURCE=1 to the compiler in your makefiles.
Correct interface parameter and return value type definitions. For example,
long curpos; curpos = lseek(fd, 0L, SEEK_CUR);
should be changed to:
off64_t curpos; curpos = lseek64(fd, (off64_t)0, SEEK_CUR);
Care must be taken to declare all the variables in an expression to be the same type. For example,
int delta; long curpos; .... curpos = lseek(fd, 0L, SEEK_CUR); curpos += delta;
should be changed to:
off64_t delta; off64_t curpos; .... curpos = lseek64(fd, (off64_t)0, SEEK_CUR); curpos += delta;
Any output or in-memory formatting strings utilized in reference to the large file sizing entities must be converted. For example,
off_t offset;
printf(" %7ld", offset);
should be modified to:
off64_t offset;
printf(" %7lld", offset);
Use the proper conversion routine. For example,
off_t offset; offset = atol(argv[1]);
should be modified to:
off64_t offset; offset = atoll(argv[1]);
The remaining 32-bit versions of functions and types should be made large file safe.
For more information, refer to the largefile(5), lf64(5), lfcompile(5), and lfcompile64(5) man pages and "Large Files in Solaris" at http://www.sun.com/software/white-papers.
Note that there is no support for large swap files or large files in tmpfs (as normally used for /tmp). The mmap(2) system call is also limited to 2 gigabytes for 32-bit systems.
The preemption control library functions allow a running LWP to give a hint to the kernel that preemptions of that LWP should be avoided. The most likely use for these functions is to block preemption while holding a spinlock. The following functions are used for preemption control:
schedctl_init(3SCHED) |
Initializes preemption control for the calling LWP |
schedctl_lookup(3SCHED) |
Returns the currently allocated preemption control data associated with the calling LWP |
schedctl_exit(3SCHED) |
Removes the preemption control data associated with the calling LWP |
schedctl_start(3SCHED) |
Gives a hint to the kernel scheduler that preemption should be avoided on the current LWP |
schedctl_stop(3SCHED) |
Removes the hint that was set by schedctl_start() |
/procThe flat /proc file system in Solaris 2.5.1 has been restructured into a directory hierarchy that contains additional subdirectories for state information and control functions. Refer to the proc(4) man page for more details.
The watchpoint facility monitors access to data and modifications of data in the process address space. For more information, refer to the proc(4) and the watchmalloc(3MALLOC) man pages.
Pluggable Authentication Modules (PAMs) allow integration of various authentication technologies such as UNIX, Kerberos, RSA, smart cards, and DCE into system entry services such as login, passwd, rlogin, telnet, ftp and su without changing any of these services. Some of the benefits PAM provides are:
The man pages associated with PAM include:
pam(3PAM)
pam_start(3PAM)
pam_authenticate(3PAM)
pam_acc_mgmt(3PAM)
pam_open_session(3PAM)
pam_chauthtok(3PAM)
pam_putenv(3PAM)
pam.conf(4)
pam_sm(3PAM)
pam_end(3PAM)
pam_set_data(3PAM)
pam_get_data(3PAM)
pam_set_item(3PAM)
pam_get_item(3PAM)
pam_strerror(3PAM)
pam_setcred(3PAM)
pam_close_session(3PAM)
pam_getenv(3PAM)
pam_getenvlist(3PAM)
pam_sm_authenticate(3PAM)
pam_sm_chauthtok(3PAM)
pam_sm_open_session(3PAM)
pam_sm_setcred(3PAM)
Refer to http://www.sun.com/solaris/pam for more information.
Dynamic Host Configuration Protocol (DHCP) is a standard developed to enable host systems in a TCP/IP network to be configured automatically for the network as they boot. DHCP uses a client/server mechanism: servers store and manage configuration information for clients and provide that information upon a client's request. The information includes the client's IP address and information about network services available to the client.
DHCP evolved from an earlier protocol, BOOTP, which was designed for booting over a TCP/IP network. DHCP builds upon BOOTP by using the same format for messages between client and sever, while including more information in the messages. The extra information is the network configuration data for the client.
A primary benefit of DHCP is its ability to manage IP address assignments through leasing, which allows IP addresses that are not in use to be reclaimed and reassigned to other clients. This enables a site to use a smaller pool of IP addresses than would be needed if all clients were assigned a permanent address.
Refer to the System Administrator Guide, Volume 3 in the Solaris 8 Document Collection and the following man pages for more details.
dhtadm(1M) - DHCP configuration table management utility
pntadm(1M) - DHCP network table management utility
dhcpconfig(1M) - DHCP service configuration utility
in.dhcpd(1M) - Dynamic Host Configuration Protocol server
ifconfig(1M) - Used at system boot to assign IP addresses to network interfaces, configure network interface parameters, or both. On a Solaris DHCP client, ifconfig starts DHCP to get the parameters (including the IP address) needed to configure a network interface.
dhcpinfo(1) - Display value of parameters received through DHCP
dhcpagent(1M) - Daemon for client Dynamic Host Configuration Protocol (DHCP)
dhcptab(4) - DHCP configuration parameter table
dhcp_network(4) - DHCP network DHCP database
dhcp(4) - File containing default parameter values for the location and type of the databases used by the DHCP service
dhcptags(4) - Removed in Solaris 8. See dhcp_inittab(4).
The following DHCP enhancements are introduced in Solaris 8:
dhcpmgr(1M) - Graphical interface for managing DHCP service
dhcp_inittab(4) - Defines aspects of DHCP option codes, such as the data type, and assigns mnemonic labels. The information in the /etc/dhcp/inittab file is used by dhcpinfo to provide more meaningful information to human readers of the information. This file replaces the /etc/dhcp/dhcptags file.
Processor sets allow the binding of processes to groups of processors, rather than just a single processor. Note that this binding does not exclude other processes from using that processor set. The use of processor sets can give increased performance by reducing thread migration between CPUs. The maintenance command and system calls associated with processor sets are briefly described below.
psrset(1M) - Creates and manages processor sets
pset_create(2) - Creates an empty processor set that contains no processors
pset_destroy(2) - Destroys a processor set, releasing its constituent processors and processes
pset_assign(2) - Assigns a processor to a processor set
pset_bind(2) - Bind LWPs to a set of processors
pset_info(2) - Get information about a processor set
The patchadd(1M) and patchrm(1M) utilities were introduced in Solaris 2.6 to manage patches, replacing the old installpatch and backoutpatch commands. See the "Patch Administration (Overview)" section in the System Administration Guide, Volume 1 in the Solaris 8 Document Collection for more details.
Two new maintenance commands provide a quick and efficient method of backing up and restoring NIS+ namespaces.
nisbackup(1M) - Backup NIS+ directories
nisrestore(1M) - Restore NIS+ directory backup
Refer to the Solaris Naming Administration Guide in the Solaris 8 Document Collection and man pages for more details.
isalist Utilitiesisalist is a set of utilities that enables users to find out which instruction sets are supported on their machines and also to determine which one performs best for them. Three new interfaces are introduced in Solaris 2.6:
isalist(1) prints out an ordered list of supported instruction sets. The following examples are from SPARC and IA platforms. Refer to isalist(5) for the complete list of instruction set names.
$ isalist sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc $ isalist pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386
The optisa(1) command accepts a list of instruction sets on the command line and prints the one that will perform best on this machine.
$ optisa `isalist` sparcv9+vis
The sysinfo(2) system call supports the new SI_ISALIST command.
The isalist utilities provide a standard interface so users can choose their application binary to obtain maximum performance. For example, a system administrator can write a wrapper script and use the output of isalist and optisa to choose the appropriate binary for a given platform.
The minimum timer interval can be reduced from 10ms to 1ms. It is set in /etc/system by adding the line:
set hires_tick=1
Note that using a 1ms timer interval will also increase involuntary context switches.
In addition to the BSD-style interval timers setitimer(2) and getitimer(2), the POSIX.1b timer functions are supported in Solaris 2.6:
timer_create(3RT) - Create a timer
timer_delete(3RT) - Delete a timer
timer_settime(3RT) - Sets the time until the next expiration of a timer
timer_gettime(3RT) - Gets the amount of time until a timer expires and the reload value
timer_getoverrun(3RT) - Returns the timer expiration overrun count for a timer
| ||||||||||||
