man Pages(7): Device Network Interfaces
Cover

SunOS Reference Manual


Sun Microsystems, Inc.
2550 Garcia Avenue
Mountain View, CA 94043
U.S.A.
Copyright 1997 Sun Microsystems, Inc. 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
Sun, Sun Microsystems, the Sun logo, SunSoft, Solaris, SunOS, OpenWindows, DeskSet, ONC, ONC+, and NFS are trademarks, or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
The OPEN LOOK and Sun(TM) Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun's licensees who implement OPEN LOOK GUIs and otherwise comply with Sun's written license agreements.
RESTRICTED RIGHTS : Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a).
DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
Copyright 1997 Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, Californie 94043-1100 Etats-Unis. Tous droits re´serve´s.
Ce produit ou document est prote´ge´ par un copyright et distribue´ avec des licences qui en restreignent l'utilisation, la copie, la distribution, et la de´compilation. Aucune partie de ce produit ou document ne peut e^tre reproduite sous aucune forme, par quelque moyen que ce soit, sans l'autorisation pre´alable et e´crite de Sun et de ses bailleurs de licence, s'il y en a. Le logiciel de´tenu par des tiers, et qui comprend la technologie relative aux polices de caracte`res, est prote´ge´ par un copyright et licencie´ par des fournisseurs de Sun.
Des parties de ce produit pourront e^tre de´rive´es des syste`mes Berkeley BSD licencie´s par l'Universite´ de Californie. UNIX est une marque de´pose´e aux Etats-Unis et dans d'autres pays et licencie´e exclusivement par X/Open Company, Ltd.
Sun, Sun Microsystems, le logo Sun, SunSoft, Solaris, SunOS, OpenWindows, DeskSet, ONC, ONC+, et NFS sont des marques de fabrique ou des marques de´pose´es, de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays. Toutes les marques SPARC sont utilise´es sous licence et sont des marques de fabrique ou des marques de´pose´es de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont base´s sur une architecture de´veloppe´e par Sun Microsystems, Inc.
L'interface d'utilisation graphique OPEN LOOK et Sun(TM) a e´te´ de´veloppe´e par Sun Microsystems, Inc. pour ses utilisateurs et licencie´s. Sun reconnai^t les efforts de pionniers de Xerox pour la recherche et le de´veloppement du concept des interfaces d'utilisation visuelle ou graphique pour l'industrie de l'informatique. Sun de´tient une licence non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, cette licence couvrant e´galement les licencie´s de Sun qui mettent en place l'interface d'utilisation graphique OPEN LOOK et qui en outre se conforment aux licences e´crites de Sun.
CETTE PUBLICATION EST FOURNIE "EN L'ETAT" ET AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, N'EST ACCORDEE, Y COMPRIS DES GARANTIES CONCERNANT LA VALEUR MARCHANDE, L'APTITUDE DE LA PUBLICATION A REPONDRE A UNE UTILISATION PARTICULIERE, OU LE FAIT QU'ELLE NE SOIT PAS CONTREFAISANTE DE PRODUIT DE TIERS. CE DENI DE GARANTIE NE S'APPLIQUERAIT PAS, DANS LA MESURE OU IL SERAIT TENU JURIDIQUEMENT NUL ET NON AVENU.
Preface

Preface

OVERVIEW
A man page is provided for both the naive user, and sophisticated user who is familiar with the SunOS operating system and is in need of on-line information. A man page is intended to answer concisely the question "What does it do?" The man pages in general comprise a reference manual. They are not intended to be a tutorial.
The following contains a brief description of each section in the man pages and the information it references:
Section 1 describes, in alphabetical order, commands available with the
operating system.
Section 1M describes, in alphabetical order, commands that are used chiefly
for system maintenance and administration purposes.
Section 2 describes all of the system calls. Most of these calls have one or
more error returns. An error condition is indicated by an otherwise impossible returned value.
Section 3 describes functions found in various libraries, other than those
functions that directly invoke UNIX system primitives, which are described in Section 2 of this volume.
i
Section 4 outlines the formats of various files. The C structure declarations
for the file formats are given where applicable.
Section 5 contains miscellaneous documentation such as character set tables,
etc.
Section 6 contains available games and demos.
Section 7 describes various special files that refer to specific hardware
peripherals, and device drivers. STREAMS software drivers, modules and the STREAMS -genericset of system calls are also described.
Section 9 provides reference information needed to write device drivers in
the kernel operating systems environment. It describes two device driver interface specifications: the Device Driver Interface (DDI) and the Driver-Kernel Interface (DKI).
Section 9E describes the DDI/DKI, DDI-only, and DKI-only entry-point
routines a developer may include in a device driver.
Section 9F describes the kernel functions available for use by device drivers.
Section 9S describes the data structures used by drivers to share
information between the driver and the kernel.
Below is a generic format for man pages. The man pages of each manual section generally follow this order, but include only needed headings. For example, if there are no bugs to report, there is no BUGS section. See the intro pages for more information and detail about each section, and man (1)for more information about man pages in general.
NAME
This section gives the names of the commands or functions documented, followed by a brief description of what they do.
SYNOPSIS
This section shows the syntax of commands or functions. When a command or file does not exist in the standard path, its full pathname is shown. Literal characters (commands and options) are in bold font and variables (arguments, parameters and substitution characters) are in italic font. Options and
ii
arguments are alphabetized, with single letter arguments first, and options with arguments next, unless a different argument order is required.
The following special characters are used in this section:
[ ]
The option or argument enclosed in these brackets is optional. If the brackets are omitted, the argument must be specified.
. . .
Ellipses. Several values may be provided for the previous argument, or the previous argument can be specified multiple times, for example, `filename . . .'.
|
Separator. Only one of the arguments separated by this character can be specified at time.
{ }
Braces. The options and/or arguments enclosed within braces are interdependent, such that everything enclosed must be treated as a unit.
PROTOCOL
This section occurs only in subsection 3R to indicate the protocol description file. The protocol specification pathname is always listed in bold font.
DESCRIPTION
This section defines the functionality and behavior of the service. Thus it describes concisely what the command does. It does not discuss OPTIONS or cite EXAMPLES. Interactive commands, subcommands, requests, macros, functions and such, are described under USAGE.
IOCTL
This section appears on pages in Section 7 only. Only the device class which supplies appropriate parameters to the ioctl(2) system call is called ioctl and generates its own heading. ioctl calls for a specific device are listed alphabetically (on the man page for that specific device). ioctl calls are used for a particular class of devices all of which have an io ending, such as mtio(7).

Preface
iii
OPTIONS
This lists the command options with a concise summary of what each option does. The options are listed literally and in the order they appear in the SYNOPSIS section. Possible arguments to options are discussed under the option, and where appropriate, default values are supplied.
OPERANDS
This section lists the command operands and describes how they affect the actions of the command.
OUTPUT
This section describes the output - standard output, standard error, or output files - generated by the command.
RETURN VALUES
If the man page documents functions that return values, this section lists these values and describes the conditions under which they are returned. If a function can return only constant values, such as 0 or -1, these values are listed in tagged paragraphs. Otherwise, a single paragraph describes the return values of each function. Functions declared as void do not return values, so they are not discussed in RETURN VALUES.
ERRORS
On failure, most functions place an error code in the global variable errno indicating why they failed. This section lists alphabetically all error codes a function can generate and describes the conditions that cause each error. When more than one condition can cause the same error, each condition is described in a separate paragraph under the error code.

iv
USAGE
This section is provided as a guidance on use. This section lists special rules, features and commands that require in-depth explanations. The subsections listed below are used to explain built-in functionality:
Commands
Modifiers
Variables
Expressions
Input Grammar
EXAMPLES
This section provides examples of usage or of how to use a command or function. Wherever possible a complete example including command line entry and machine response is shown. Whenever an example is given, the prompt is shown as
example%
or if the user must be super-user,
example#
Examples are followed by explanations, variable substitution rules, or returned values. Most examples illustrate concepts from the SYNOPSIS, DESCRIPTION, OPTIONS and USAGE sections.
ENVIRONMENT
This section lists any environment variables that the command or function affects, followed by a brief description of the effect.
EXIT STATUS
This section lists the values the command returns to the calling program or shell and the conditions that cause these values to be returned. Usually, zero is returned for successful completion and values other than zero for various error conditions.

FILES

Preface
v
This section lists all filenames referred to by the man page, files of interest, and files created or required by commands. Each is followed by a descriptive summary or explanation.
ATTRIBUTES
This section lists characteristics of commands, utilities, and device drivers by defining the attribute type and its corresponding value. (See attributes(5) for more information.)
SEE ALSO
This section lists references to other man pages, in-house documentation and outside publications.
DIAGNOSTICS
This section lists diagnostic messages with a brief explanation of the condition causing the error. Messages appear in bold font with the exception of variables, which are in italic font.
WARNINGS
This section lists warnings about special conditions which could seriously affect your working conditions -- this is not a list of diagnostics.
NOTES
This section lists additional information that does not belong anywhere else on the page. It takes the form of an aside to the user, covering points of special interest. Critical information is never covered here.
BUGS
This section describes known bugs and wherever possible suggests workarounds.

vi
intro(7)

NAME

Intro, intro - introduction to special files

DESCRIPTION

This section describes various device and network interfaces available on the system. The types of interfaces described include character and block devices, STREAMS modules, network protocols, file systems, and ioctl requests for driver subsystems and classes.
This section contains the following major collections:
(7D)
The system provides drivers for a variety of hardware devices, such as disk, magnetic tapes, serial communication lines, mice, and frame buffers, as well as virtual devices such as pseudo-terminals and windows.
This section describes special files that refer to specific hardware peripherals and device drivers. STREAMS device drivers are also described. Characteristics of both the hardware device and the corresponding device driver are discussed where applicable.
An application accesses a device through that device's special file. This section specifies the device special file to be used to access the device as well as application programming interface (API) information relevant to the use of the device driver.
All device special files are located under the /devices directory. The /devices directory hierarchy attempts to mirror the hierarchy of system busses, controllers, and devices configured on the system. Logical device names for special files in /devices are located under the /dev directory. Although not every special file under /devices will have a corresponding logical entry under /dev, whenever possible, an application should reference a device using the logical name for the device. Logical device names are listed in the FILES section of the page for the device in question.
This section also describes driver configuration where applicable. Many device drivers have a driver configuration file of the form driver_name.conf associated with them (see driver.conf(4)). The configuration information stored in the driver configuration file is used to configure the driver and the device. Driver configuration files are located in /kernel/drv and /usr/kernel/drv. Driver configuration files for platform dependent drivers are located in /platform/`uname -i`/kernel/drv where `uname -i` is the output of the uname(1) command with the -i option.
Some driver configuration files may contain user configurable properties. Changes in a driver's configuration file will not take effect until the system is rebooted or the driver has been removed and re-added (see rem_drv(1M) and add_drv(1M)).
(7FS)
This section describes the programmatic interface for several file systems supported by SunOS.
(7I)
This section describes ioctl requests which apply to a class of drivers or subsystems. For example, ioctl requests which apply to most tape devices are
discussed in mtio(7I). Ioctl requests relevant to only a specific device are described on the man page for that device. The page for the device in question should still be examined for exceptions to the ioctls listed in section 7I.
(7M)
This section describes STREAMS modules. Note that STREAMS drivers are discussed in section 7D. streamio(7I) contains a list of ioctl requests used to manipulate STREAMS modules and interface with the STREAMS framework. Ioctl requests specific to a STREAMS module will be discussed on the man page for that module.
(7P)
This section describes various network protocols available in SunOS.
SunOS supports both socket-based and STREAMS -basednetwork communications. The Internet protocol family, described in inet(7P), is the primary protocol family supported by SunOS, although the system can support a number of others. The raw interface provides low-level services, such as packet fragmentation and reassembly, routing, addressing, and basic transport for socket-based implementations. Facilities for communicating using an Internet-family protocol are generally accessed by specifying the AF_INET address family when binding a socket; see socket(3N) for details.
Major protocols in the Internet family include:
The Internet Protocol (IP) itself, which supports the universal datagram format, as described in ip(7P). This is the default protocol for SOCK_RAW type sockets within the AF_INET domain.
The Transmission Control Protocol (TCP); see tcp(7P). This is the default protocol for SOCK_STREAM type sockets.
The User Datagram Protocol (UDP); see udp(4P). This is the default protocol for SOCK_DGRAM type sockets.
The Address Resolution Protocol (ARP); see arp (7P).
The Internet Control Message Protocol (ICMP); see icmp(7P).

SEE ALSO

add_drv(1M), rem_drv(1M), intro(2), ioctl(2), socket(3N), driver.conf(4), arp (7P), icmp(7P), inet(7P), ip(7P), mtio(7I), st(7D), streamio(7I), tcp(7P), udp(7P)
Solaris 1.x to 2.x Transition Guide
TCP/IP and Data Communications Administration Guide
STREAMS Programming Guide
Writing Device Drivers
Name
Description
adp(7D)
low-level module for Adaptec
7870/7871/7872/7880/7881/7882-based SCSI
controllers
aha(7D)
low-level module for Adaptec 154x ISA host bus
adapters
aic(7D)
low-level module for Adaptec AIC-6360 based ISA
host bus adapters
arp (7P)
Address Resolution Protocol
ARP(7P)
See arp (7P)
asy (7D)
asynchronous serial port driver
ata(7D)
AT attachment disk driver
audio(7I)
generic audio device interface
audioamd(7D)
telephone quality audio device
audiocs(7D)
Crystal Semiconductor 4231 audio Interface
bd(7M)
SunButtons and SunDials STREAMS module
be(7D)
BigMAC Fast Ethernet device driver
blogic(7D)
low-level module for Mylex/BusLogic host bus
adapters
bpp(7D)
bi-directional parallel port driver
bufmod(7M)
STREAMS Buffer Module
bwtwo(7D)
black and white memory frame buffer
cdio(7I)
CD-ROM control operations
cgeight(7D)
24-bit color memory frame buffer
cgfour(7D)
P4-bus 8-bit color memory frame buffer
cgfourteen(7D)
24-bit color graphics device
cgsix(7D)
accelerated 8-bit color frame buffer
cgthree(7D)
8-bit color memory frame buffer
cgtwo(7D)
color graphics interface
cmdk(7D)
common disk driver
connld(7M)
line discipline for unique stream connections
console(7D)
STREAMS-based console interface
corvette(7D)
low-level module for IBM Micro Channel SCSI-2
Fast/Wide Adapter/A
cpr(7)
suspend and resume module
csa(7D)
low-level module for Compaq SMART SCSI Array
Controller
dbri(7D)
Dual Basic Rate ISDN and audio Interface
display(7D)
system console display
dkio(7I)
disk control operations
dlpi(7P)
Data Link Provider Interface
dnet(7D)
Ethernet driver for DEC 21040, 21041, 21140 Ether-
net cards
dpt(7D)
DPT 2011, 2012, 2021, 2022, 2122, 2024, 2124, 3021,
3222, and 3224 controllers
dsa(7D)
low-level module for Dell SCSI Array Controller
(DSA)
ecpp(7D)
IEEE 1284 ecp, nibble and centronics compatible
parallel port driver
eepro(7D)
Intel EtherExpress-Pro Ethernet device driver
eha(7D)
low-level module for Adaptec 174x EISA host bus
adapter
el(7D)
3COM 3C503 Ethernet device driver
elink(7D)
3COM 3C507 Ethernet device driver
elx(7D)
3COM EtherLink III Ethernet device driver
esa(7D)
low-level module for Adaptec 7770 based SCSI con-
trollers
esp(7D)
ESP SCSI Host Bus Adapter Driver
fas(7D)
FAS SCSI Host Bus Adapter Driver
fbio(7I)
frame buffer control operations
fd (7D)
drivers for floppy disks and floppy disk controllers
fdc(7D)
See fd (7D)
fdio(7I)
floppy disk control operations
ffb(7D)
24-bit UPA color frame buffer and graphics
accelerator
gld (7D)
Generic LAN Driver
glm(7D)
GLM SCSI Host Bus Adapter Driver
hdio(7I)
SMD and IPI disk control operations
hme (7D)
SUNW,hme Fast-Ethernet device driver
hsfs(7FS)
High Sierra & ISO 9660 CD-ROM filesystem
icmp(7P)
Internet Control Message Protocol
ICMP(7P)
See icmp(7P)
id(7D)
See ipi(7D)
ie(7D)
Intel 82586 Ethernet device driver
iee(7D)
Intel EtherExpress 16 Ethernet device driver
ieef(7D)
Intel EtherExpress Flash32/82596 Ethernet device
driver
if(7P)
See if_tcp(7P)
if_tcp(7P)
general properties of Internet Protocol network
interfaces
inet(7P)
Internet protocol family
ip(7P)
Internet Protocol
IP (7P)
See ip(7P)
ipd(7M)
See ppp(7M)
ipdcm(7M)
See ppp(7M)
ipdptp(7M)
See ppp(7M)
ipi(7D)
IPI driver
ipi3sc(7D)
See ipi(7D)
iprb(7D)
Intel 82557 (D100)-controlled Network Cards
is(7D)
See ipi(7D)
isdnio(7I)
ISDN interfaces
isp(7D)
ISP SCSI Host Bus Adapter Driver
iss(7D)
low-level module for Tricord System's SCSI host
bus adapter
kb(7M)
keyboard STREAMS module
kdmouse(7D)
built-in mouse device interface
keyboard(7D)
system console keyboard
kmem(7D)
See mem(7D)
kstat(7D)
kernel statistics driver
ksyms(7D)
kernel symbols
ldterm(7M)
standard STREAMS terminal line discipline module
le(7D)
Am7990 (LANCE) Ethernet device driver
lebuffer(7D)
See le(7D)
ledma(7D)
See le(7D)
leo(7D)
double-buffered 24-bit SBus color frame buffer and
graphics accelerator
llc1(7D)
Logical Link Control Protocol Class 1 Driver
lockstat(7D)
kernel lock statistics driver
lofs(7FS)
loopback virtual file system
log(7D)
interface to STREAMS error logging and event trac-
ing
logi(7D)
LOGITECH Bus Mouse device interface
lp(7D)
driver for parallel port
ltem(7D)
ANSI Layered Console Driver
m64(7D)
8-bit PCI color memory frame buffer
mcis(7D)
low-level module for IBM MicroChannel host bus
adapter
mcpp(7D)
ALM-2 Parallel Printer port driver
mcpzsa(7D)
ALM-2 Zilog 8530 SCC serial communications
driver
mem(7D)
physical or virtual memory
mic(7D)
Multi-interface Chip driver
mlx(7D)
low-level module for Mylex DAC960E EISA, Mylex
DAC960P/PD/PD-Ultra/PL PCI, and IBM
DMC960 Micro Channel host bus adapter series
msm(7D)
Microsoft Bus Mouse device interface
mt(7D)
tape interface
mtio(7I)
general magnetic tape interface
ncrs(7D)
low-level module for NCR 53C710, 53C810, 53C815,
53C820, and 53C825 host bus adapters
nee(7D)
Novell NE3200 Ethernet device Driver
nei(7D)
Novell NE2000, NE2000plus Ethernet device Driver
nfe (7D)
Compaq Netflex-2 Dualport Ethernet and
ENET/TR Drivers
null(7D)
the null file
openprom(7D)
PROM monitor configuration interface
pcelx(7D)
3COM EtherLink III PCMCIA Ethernet Adapter
pcfs(7FS)
DOS formatted file system
pcic(7D)
Intel i82365SL PC Card Interface Controller
pckt(7M)
STREAMS Packet Mode module
pcmem(7D)
PCMCIA memory card nexus driver
pcn(7D)
AMD PCnet Ethernet controller device driver
pcram(7D)
PCMCIA RAM memory card device driver
pcscsi(7D)
low-level module for the AMD PCscsi, PCscsi II,
PCnet-SCSI, and Qlogic QLA510 PCI-to-SCSI bus
adapters
pcser(7D)
PCMCIA serial card device driver
pe(7D)
Xircom Pocket Ethernet device driver
pfmod(7M)
STREAMS Packet Filter Module
pipemod(7M)
STREAMS pipe flushing module
pln(7D)
SPARCstorage Array SCSI Host Bus Adapter Driver
pm (7D)
power management driver
pmc(7D)
Platform Management Chip driver
pn(7D)
See ipi(7D)
ppp(7M)
STREAMS modules and drivers for the Point-to-
Point Protocol
ppp_diag(7M)
See ppp(7M)
ptem(7M)
STREAMS Pseudo Terminal Emulation module
ptm(7D)
STREAMS pseudo-tty master driver
pts(7D)
STREAMS pseudo-tty slave driver
pty (7D)
pseudo-terminal driver
qe(7D)
QEC/MACE Ethernet device driver
qec(7D)
QEC bus nexus device driver
quotactl(7I)
manipulate disk quotas
riles(7D)
device driver for the Racal Interlan ES-3210 Ether-
net Adapter
rns_smt(7D)
Rockwell Station Management driver
sad(7D)
STREAMS Administrative Driver
sbpro(7D)
Sound Blaster Pro, Sound Blaster 16, and Sound
Blaster AWE32 audio device driver
sd(7D)
driver for SCSI disk and CD-ROM devices
se(7D)
Siemens 82532 ESCC serial communications driver
se_hdlc(7D)
on-board high-performance serial HDLC interface
ses(7D)
SCSI enclosure services device driver
sesio(7I)
enclosure services device driver interface
sf(7D)
SOC+ FC-AL FCP Driver
smc(7D)
SMC 8003/8013/8216/8416 Ethernet device driver
smce(7D)
SMC 3032/EISA dual-channel Ethernet device
driver
smceu(7D)
SMC Elite32 Ultra (8232) Ethernet device driver
smcf(7D)
SMC Ether100 (9232) Ethernet device driver
soc(7D)
Serial Optical Controller (SOC) device driver
socal(7D)
Serial Optical Controller for Fibre Channel Arbi-
trated Loop (SOC+) device driver
sockio(7I)
ioctls that operate directly on sockets
ssd(7D)
driver for SPARCstorage Array and Fibre Channel
Arbitrated Loop disk devices
st(7D)
driver for SCSI tape devices
stc(7D)
Serial Parallel Communications driver for SBus
stp4020(7D)
STP 4020 PCMCIA Adapter
streamio(7I)
STREAMS ioctl commands
sxp(7D)
Rockwell 2200 SNAP Streams Driver
tcp(7P)
Internet Transmission Control Protocol
TCP (7P)
See tcp(7P)
tcx(7D)
24-bit SBus color memory frame buffer
termio (7I)
general terminal interface
termiox (7I)
extended general terminal interface
ticlts(7D)
loopback transport providers
ticots(7D)
See ticlts(7D)
ticotsord(7D)
See ticlts(7D)
timod(7M)
Transport Interface cooperating STREAMS module
tiqmouse(7D)
integrated mouse device interface
tirdwr(7M)
Transport Interface read/write interface STREAMS
module
tmpfs(7FS)
memory based filesystem
tpf(7D)
Platform Specific Module (PSM) for Tricord Sys-
tems Enterprise Server Models ES3000, ES4000 and
ES5000.
tr(7D)
IBM 16/4 Token Ring Network Adapter device
driver
trantor(7D)
low-level module for Trantor T348 Parallel SCSI
host bus adapter
ttcompat(7M)
V7, 4BSD and XENIX STREAMS compatibility
module
tty(7D)
controlling terminal interface
udp(7P)
Internet User Datagram Protocol
UDP(7P)
See udp(7P)
visual_io(7I)
Solaris VISUAL I/O control operations
volfs(7FS)
Volume Management file system
vuid2ps2(7M)
See vuidmice(7M)
vuid3ps2(7M)
See vuidmice(7M)
vuidm3p(7M)
See vuidmice(7M)
vuidm4p(7M)
See vuidmice(7M)
vuidm5p(7M)
See vuidmice(7M)
vuidmice(7M)
converts mouse protocol to Firm Events
wscons(7D)
workstation console
xd(7D)
disk driver for Xylogics 7053 SMD Disk Controller
xdc(7D)
See xd(7D)
xt(7D)
driver for Xylogics 472 1/2 inch tape controller
xy(7D)
disk driver for Xylogics 450 and 451 SMD Disk Con-
trollers
xyc (7D)
See xy(7D)
zero(7D)
source of zeroes
zs(7D)
Zilog 8530 SCC serial communications driver
zsh(7D)
On-board serial HDLC/SDLC interface
ARP(7P)

NAME

arp, ARP - Address Resolution Protocol

SYNOPSIS

#include <sys/fcntl.h>
#include <sys/socket.h>
#include <net/if_arp.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_DGRAM ,0);
d = open ("/dev/arp", oflag);

DESCRIPTION

ARP is a protocol used to map dynamically between Internet Protocol (IP) and 10Mb/s Ethernet addresses. It is used by all the 10Mb/s Ethernet datalink providers (interface drivers) and it can be used by other datalink providers that support broadcast (such as FDDI and Token Ring). ARP is not specific to the Internet Protocol but this implementation supports only that network layer protocol.
ARP caches IP-to-Ethernet address mappings. When an interface requests a mapping for an address not in the cache, ARP queues the message that requires the mapping and broadcasts a message on the associated network requesting the address mapping. If a response is provided, the new mapping is cached and any pending message is transmitted. ARP will queue at most four packets while waiting for a mapping request to be responded to; only the four most recently transmitted packets are kept.

APPLICATION PROGRAMMING

The STREAMS device /dev/arp is not a Transport Level Interface (TLI) transport provider and may not be used with the TLI interface.

INTERFACE

To facilitate communications with systems which do not use ARP, ioctl( ) requests are provided to enter and delete entries in the IP-to-Ethernet tables.
#include <sys/sockio.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_arp.h>
struct arpreq arpreq;
ioctl(s, SIOCSARP ,(caddr_t)&arpreq);
ioctl(s, SIOCGARP ,(caddr_t)&arpreq);
ioctl(s, SIOCDARP ,(caddr_t)&arpreq);
Each ioctl( ) request takes the same structure as an argument. SIOCSARP sets an ARP entry, SIOCGARP gets an ARP entry, and SIOCDARP deletes an ARP entry. These ioctl( ) requests may be applied to any Internet family socket descriptor s, or to a descriptor for the ARP device, but only by the privileged user.
The arpreq structure contains:
/*
* ARP ioctl request
* /
struct arpreq {
        struct sockaddr   arp_pa;             /* protocol address * /
        struct sockaddr   arp_ha;             /* hardware address * /
        int               arp_flags;           /* flags * /
};
/* arp_flags field values * /
#define ATF_COM             0x2 /* completed entry (arp_ha valid) * /
#define ATF_PERM            0x4 /* permanent entry * /
#define ATF_PUBL            0x8 /* publish (respond for other host) * /
#define ATF_USETRAILERS 0x10 /* send trailer packets to host * /
The address family for the arp_pa sockaddr must be AF_INET; for the arp_ha sockaddr it must be AF_UNSPEC. The only flag bits that may be written are ATF_PUBL and ATF_USETRAILERS. ATF_PERM makes the entry permanent if the ioctl( ) request succeeds. The peculiar nature of the ARP tables may cause the ioctl( ) request to fail if too many permanent IP addresses hash to the same slot. ATF_PUBL specifies that the ARP code should respond to ARP requests for the indicated host coming from other machines. This allows a host to act as an " ARPserver", which may be useful in convincing an ARP-only machine to talk to a non-ARP machine.
ARP is also used to negotiate the use of trailer IP encapsulations; trailers are an alternate encapsulation used to allow efficient packet alignment for large packets despite variablesized headers. Hosts that wish to receive trailer encapsulations so indicate by sending gratuitous ARP translation replies along with replies to IP requests; they are also sent in reply to IP translation replies. The negotiation is thus fully symmetrical, in that either or both hosts may request trailers. The ATF_USETRAILERS flag is used to record the receipt of such a reply, and enables the transmission of trailer packets to that host.
ARP watches passively for hosts impersonating the local host (that is, a host which responds to an ARP mapping request for the local host's address).

SEE ALSO

arp (1M),ifconfig (1M),if_tcp(7P), inet(7P)
Plummer, Dave, ``An Ethernet Address Resolution Protocol -or- Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware,'' RFC 826, Network Information Center, SRI International, Menlo Park, Calif., November 1982.
Leffler, Sam, and Michael Karels, ``Trailer Encapsulations,'' RFC 893, Network Information Center, SRI International, Menlo Park, Calif., April 1984.

DIAGNOSTICS

IP: Hardware address '%x:%x:%x:%x:%x:%x' trying to be our address '%d.%d.%d.%d'!
Duplicate IP address. ARP has discovered another host on the local network which responds to mapping requests for the Internet address of this system.
IP: Proxy ARP problem? Hardware address '%x:%x:%x:%x:%x:%x' thinks it is
'%d.%d.%d.%d'
This message will appear if arp (1M)has been used to create a published entry and some other host on the local network responds to mapping requests for the published arp entry.
ICMP(7P)

NAME

icmp, ICMP - Internet Control Message Protocol

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip_icmp.h>
s = socket(AF_INET, SOCK_RAW ,proto);
t = t_open("/dev/icmp", O_RDWR);

DESCRIPTION

ICMP is the error and control message protocol used by the Internet protocol family. It is used by the kernel to handle and report errors in protocol processing. It may also be accessed by programs using the socket interface or the Transport Level Interface (TLI) for network monitoring and diagnostic functions. When used with the socket interface, a "raw socket" type is used. The protocol number for ICMP, used in the proto parameter to the socket call, can be obtained from getprotobyname(3N). ICMP file descriptors and sockets are connectionless, and are normally used with the t_sndudata / t_rcvudata and the sendto( ) / recvfrom( ) calls.
Outgoing packets automatically have an Internet Protocol (IP) header prepended to them. Incoming packets are provided to the user with the IP header and options intact.
ICMP is an datagram protocol layered above IP. It is used internally by the protcol code for various purposes including routing, fault isolation, and congestion control. Receipt of an ICMP "redirect" message will add a new entry in the routing table, or modify an existing one. ICMP messages are routinely sent by the protocol code. Received ICMP messages may be reflected back to users of higher-level protocols such as TCP or UDP as error returns from system calls. A copy of all ICMP message received by the system is provided to every holder of an open ICMP socket or TLI descriptor.

SEE ALSO

getprotobyname(3N), recv(3N), send(3N), t_rcvudata(3N), t_sndudata(3N), routing(4), inet(7P), ip(7P)
Postel, Jon, Internet Control Message Protocol -- DARPA Internet Program Protocol Specification, RFC 792, Network Information Center, SRI International, Menlo Park, Calif., September 1981.

DIAGNOSTICS

A socket operation may fail with one of the following errors returned:
EISCONN
An attempt was made to establish a connection on a socket which already has one, or when trying to send a datagram with the destination address specified and the socket is already connected.
ENOTCONN
An attempt was made to send a datagram, but no destination address is specified, and the socket has not been connected.
ENOBUFS
The system ran out of memory for an internal data structure.
EADDRNOTAVAIL
An attempt was made to create a socket with a network address for which no network interface exists.

NOTES

Replies to ICMP "echo" messages which are source routed are not sent back using inverted source routes, but rather go back through the normal routing mechanisms.
IP(7P)

NAME

ip, IP - Internet Protocol

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_RAW ,proto);
t = t_open ("/dev/rawip", O_RDWR );

DESCRIPTION

IP is the internetwork datagram delivery protocol that is central to the Internet protocol family. Programs may use IP through higher-level protocols such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), or may interface directly to IP. See tcp(7P) and udp(7P). Direct access may be via the socket interface (using a "raw socket") or the Transport Level Interface (TLI). The protocol options defined in the IP specification may be set in outgoing datagrams.

APPLICATION PROGRAMMING

The STREAMS driver /dev/rawip is the TLI transport provider that provides raw access to IP.

INTERFACE

Raw IP sockets are connectionless and are normally used with the sendto( ) and recvfrom( ) calls (see send(3N) and recv(3N)), although the connect(3N) call may also be used to fix the destination for future datagrams (in which case the read (2)or recv(3N) and write(2) or send(3N) calls may be used). If proto is IPPROTO_RAW or IPPROTO_IGMP ,the application is expected to include a complete IP header when sending. Otherwise, that protocol number will be set in outgoing datagrams and used to filter incoming datagrams and an IP header will be generated and prepended to each outgoing datagram. In either case, received datagrams are returned with the IP header and options intact.
The socket options supported at the IP level are:
IP_OPTIONS
IP options for outgoing datagrams. This socket option may
be used to set IP options to be included in each outgoing
datagram. IP options to be sent are set with setsockopt( )
(see getsockopt(3N)). The getsockopt(3N) call returns the IP options set in the last setsockopt( ) call. IP options on
received datagrams are visible to user programs only using
raw IP sockets. The format of IP options given in set-
sockopt( ) matches those defined in the IP specification with
one exception: the list of addresses for the source routing
options must include the first-hop gateway at the beginning
of the list of gateways. The first-hop gateway address will be extracted from the option list and the size adjusted accord-
ingly before use. IP options may be used with any socket
type in the Internet family.
IP_ADD_MEMBERSHIP
Join a multicast group.
IP_DROP_MEMBERSHIP
Leave a multicast group.
These options take a struct ip_mreq as the parameter. The structure contains a multicast address which has to be set to the CLASS-D IP multicast address, and an interface address. Normally the interface address is set to INADDR_ANY which causes the kernel to choose the interface to join on.
IP_MULTICAST_IF
The outgoing interface for multicast packets. This option
takes a struct in_addr as an argument and it selects that
interface for outgoing IP multicast packets. If the address
specified is INADDR_ANY ,it will use the unicast routing
table to select the outgoing interface (which is the default
behavior).
IP_MULTICAST_TTL
Time to live for multicast datagrams. This option takes an
unsigned character as an argument. Its value is the TTL that
IP will use on outgoing multicast datagrams. The default is
1 .
IP_MULTICAST_LOOP
Loopback for multicast datagrams. Normally multicast
datagrams are delivered to members on the sending host.
Setting the unsigned character argument to 0 will cause the
opposite behavior.
The multicast socket options can be used with any datagram socket type in the Internet family.
At the socket level, the socket option SO_DONTROUTE may be applied. This option forces datagrams being sent to bypass routing and forwarding by forcing the IP Time To Live field to 1 (meaning that the packet will not be forwarded by routers).
Raw IP datagrams can also be sent and received using the TLI connectionless primitives.
Datagrams flow through the IP layer in two directions: from the network up to user processes and from user processes down to the network. Using this orientation, IP is layered above the network interface drivers and below the transport protocols such as UDP and TCP. The Internet Control Message Protocol (ICMP) is logically a part of IP. See icmp(7P).
IP provides for a checksum of the header part, but not the data part, of the datagram. The checksum value is computed and set in the process of sending datagrams and checked when receiving datagrams.
IP options in received datagrams are processed in the IP layer according to the protocol specification. Currently recognized IP options include: security, loose source and record route (LSRR), strict source and record route (SSRR), record route, and internet timestamp.
The IP layer will normally act as a router (forwarding datagrams that are not addressed to it, among other things) when the machine has two or more interfaces that are up. This behavior can be overridden by using ndd(1M) to to set the /dev/ip variable, ip_forwarding. The value 0 means do not forward; the value 1 means forward. The initialization scripts (see /etc/init.d/inetinit) set this value at boot time based on the number of "up" interfaces, but will not turn on IP forwarding at all if the file /etc/notrouter exists. When the IP module is loaded, ip_forwarding is 0 and remains so if:
only one non-DHCP-managed interface is up (the most common case) the file /etc/notrouter exists and DHCP does not say that IP forwarding is on the file /etc/defaultrouter exists and DHCP does not say IP forwarding is on
Otherwise, ip_forwarding will be set to 1 .
The IP layer will send an ICMP message back to the source host in many cases when it receives a datagram that can not be handled. A "time exceeded" ICMP message will be sent if the "time to live" field in the IP header drops to zero in the process of forwarding a datagram. A "destination unreachable" message will be sent if a datagram can not be forwarded because there is no route to the final destination, or if it can not be fragmented. If the datagram is addressed to the local host but is destined for a protocol that is not supported or a port that is not in use, a destination unreachable message will also be sent. The IP layer may send an ICMP "source quench" message if it is receiving datagrams too quickly. ICMP messages are only sent for the first fragment of a fragmented datagram and are never returned in response to errors in other ICMP messages.
The IP layer supports fragmentation and reassembly. Datagrams are fragmented on output if the datagram is larger than the maximum transmission unit (MTU) of the network interface. Fragments of received datagrams are dropped from the reassembly queues if the complete datagram is not reconstructed within a short time period.
Errors in sending discovered at the network interface driver layer are passed by IP back up to the user process.

SEE ALSO

ndd(1M), read (2),write(2), bind(3N), connect(3N), getsockopt(3N), recv(3N), send(3N), routing(4), icmp(7P), if_tcp(7P), inet(7P), tcp(7P), udp(7P)
Postel, J., Internet Protocol - DARPA Internet Program Protocol Specification, RFC 791, Information Sciences Institute, University of Southern California, September 1981.
Braden, R., Requirements for Internet Hosts - Communication Layers, RFC 1122, Information Sciences Institute, University of Southern California, October 1989.

DIAGNOSTICS

A socket operation may fail with one of the following errors returned:
EACCES
A bind( ) operation was attempted with a "reserved" port number and the effective user ID of the process was not the privileged user.
EADDRINUSE
A bind( ) operation was attempted on a socket with a network address/port pair that has already been bound to another socket.
EADDRNOTAVAIL
A bind( ) operation was attempted for an address that is not
configured on this machine.
EINVAL
A sendmsg( ) operation with a non-NULL msg_accrights was attempted.
EINVAL
A getsockopt( ) or setsockopt( ) operation with an unknown socket option name was given.
EINVAL
A getsockopt( ) or setsockopt( ) operation was attempted with the IP option field improperly formed; an option field was shorter than the minimum value or longer than the option buffer provided.
EISCONN
A connect( ) operation was attempted on a socket on which a connect( ) operation had already been performed, and the socket could not be successfully disconnected before making the new connection.
EISCONN
A sendto( ) or sendmsg( ) operation specifying an address to which the message should be sent was attempted on a socket on which a connect( ) operation had already been performed.
EMSGSIZE
A send( ), sendto( ), or sendmsg( ) operation was attempted to send a datagram that was too large for an interface, but was not allowed to be fragmented (such as broadcasts).
ENETUNREACH
An attempt was made to establish a connection via connect( ), or to send a datagram via sendto( ) or sendmsg( ), where there was no matching entry in the routing table; or if an ICMP "destination unreachable" message was received.
ENOTCONN
A send( ) or write( ) operation, or a sendto( ) or sendmsg( ) operation not specifying an address to which the message should be sent, was attempted on a socket on which a connect( ) operation had not already been performed.
ENOBUFS
The system ran out of memory for fragmentation buffers or other internal data structures.

NOTES

Raw sockets should receive ICMP error packets relating to the protocol; currently such packets are simply discarded.
Users of higher-level protocols such as TCP and UDP should be able to see received IP options.
Intro(7)

NAME

Intro, intro - introduction to special files

DESCRIPTION

This section describes various device and network interfaces available on the system. The types of interfaces described include character and block devices, STREAMS modules, network protocols, file systems, and ioctl requests for driver subsystems and classes.
This section contains the following major collections:
(7D)
The system provides drivers for a variety of hardware devices, such as disk, magnetic tapes, serial communication lines, mice, and frame buffers, as well as virtual devices such as pseudo-terminals and windows.
This section describes special files that refer to specific hardware peripherals and device drivers. STREAMS device drivers are also described. Characteristics of both the hardware device and the corresponding device driver are discussed where applicable.
An application accesses a device through that device's special file. This section specifies the device special file to be used to access the device as well as application programming interface (API) information relevant to the use of the device driver.
All device special files are located under the /devices directory. The /devices directory hierarchy attempts to mirror the hierarchy of system busses, controllers, and devices configured on the system. Logical device names for special files in /devices are located under the /dev directory. Although not every special file under /devices will have a corresponding logical entry under /dev, whenever possible, an application should reference a device using the logical name for the device. Logical device names are listed in the FILES section of the page for the device in question.
This section also describes driver configuration where applicable. Many device drivers have a driver configuration file of the form driver_name.conf associated with them (see driver.conf(4)). The configuration information stored in the driver configuration file is used to configure the driver and the device. Driver configuration files are located in /kernel/drv and /usr/kernel/drv. Driver configuration files for platform dependent drivers are located in /platform/`uname -i`/kernel/drv where `uname -i` is the output of the uname(1) command with the -i option.
Some driver configuration files may contain user configurable properties. Changes in a driver's configuration file will not take effect until the system is rebooted or the driver has been removed and re-added (see rem_drv(1M) and add_drv(1M)).
(7FS)
This section describes the programmatic interface for several file systems supported by SunOS.
(7I)
This section describes ioctl requests which apply to a class of drivers or subsystems. For example, ioctl requests which apply to most tape devices are
discussed in mtio(7I). Ioctl requests relevant to only a specific device are described on the man page for that device. The page for the device in question should still be examined for exceptions to the ioctls listed in section 7I.
(7M)
This section describes STREAMS modules. Note that STREAMS drivers are discussed in section 7D. streamio(7I) contains a list of ioctl requests used to manipulate STREAMS modules and interface with the STREAMS framework. Ioctl requests specific to a STREAMS module will be discussed on the man page for that module.
(7P)
This section describes various network protocols available in SunOS.
SunOS supports both socket-based and STREAMS -basednetwork communications. The Internet protocol family, described in inet(7P), is the primary protocol family supported by SunOS, although the system can support a number of others. The raw interface provides low-level services, such as packet fragmentation and reassembly, routing, addressing, and basic transport for socket-based implementations. Facilities for communicating using an Internet-family protocol are generally accessed by specifying the AF_INET address family when binding a socket; see socket(3N) for details.
Major protocols in the Internet family include:
The Internet Protocol (IP) itself, which supports the universal datagram format, as described in ip(7P). This is the default protocol for SOCK_RAW type sockets within the AF_INET domain.
The Transmission Control Protocol (TCP); see tcp(7P). This is the default protocol for SOCK_STREAM type sockets.
The User Datagram Protocol (UDP); see udp(4P). This is the default protocol for SOCK_DGRAM type sockets.
The Address Resolution Protocol (ARP); see arp (7P).
The Internet Control Message Protocol (ICMP); see icmp(7P).

SEE ALSO

add_drv(1M), rem_drv(1M), intro(2), ioctl(2), socket(3N), driver.conf(4), arp (7P), icmp(7P), inet(7P), ip(7P), mtio(7I), st(7D), streamio(7I), tcp(7P), udp(7P)
Solaris 1.x to 2.x Transition Guide
TCP/IP and Data Communications Administration Guide
STREAMS Programming Guide
Writing Device Drivers
Name
Description
adp(7D)
low-level module for Adaptec
7870/7871/7872/7880/7881/7882-based SCSI
controllers
aha(7D)
low-level module for Adaptec 154x ISA host bus
adapters
aic(7D)
low-level module for Adaptec AIC-6360 based ISA
host bus adapters
arp (7P)
Address Resolution Protocol
ARP(7P)
See arp (7P)
asy (7D)
asynchronous serial port driver
ata(7D)
AT attachment disk driver
audio(7I)
generic audio device interface
audioamd(7D)
telephone quality audio device
audiocs(7D)
Crystal Semiconductor 4231 audio Interface
bd(7M)
SunButtons and SunDials STREAMS module
be(7D)
BigMAC Fast Ethernet device driver
blogic(7D)
low-level module for Mylex/BusLogic host bus
adapters
bpp(7D)
bi-directional parallel port driver
bufmod(7M)
STREAMS Buffer Module
bwtwo(7D)
black and white memory frame buffer
cdio(7I)
CD-ROM control operations
cgeight(7D)
24-bit color memory frame buffer
cgfour(7D)
P4-bus 8-bit color memory frame buffer
cgfourteen(7D)
24-bit color graphics device
cgsix(7D)
accelerated 8-bit color frame buffer
cgthree(7D)
8-bit color memory frame buffer
cgtwo(7D)
color graphics interface
cmdk(7D)
common disk driver
connld(7M)
line discipline for unique stream connections
console(7D)
STREAMS-based console interface
corvette(7D)
low-level module for IBM Micro Channel SCSI-2
Fast/Wide Adapter/A
cpr(7)
suspend and resume module
csa(7D)
low-level module for Compaq SMART SCSI Array
Controller
dbri(7D)
Dual Basic Rate ISDN and audio Interface
display(7D)
system console display
dkio(7I)
disk control operations
dlpi(7P)
Data Link Provider Interface
dnet(7D)
Ethernet driver for DEC 21040, 21041, 21140 Ether-
net cards
dpt(7D)
DPT 2011, 2012, 2021, 2022, 2122, 2024, 2124, 3021,
3222, and 3224 controllers
dsa(7D)
low-level module for Dell SCSI Array Controller
(DSA)
ecpp(7D)
IEEE 1284 ecp, nibble and centronics compatible
parallel port driver
eepro(7D)
Intel EtherExpress-Pro Ethernet device driver
eha(7D)
low-level module for Adaptec 174x EISA host bus
adapter
el(7D)
3COM 3C503 Ethernet device driver
elink(7D)
3COM 3C507 Ethernet device driver
elx(7D)
3COM EtherLink III Ethernet device driver
esa(7D)
low-level module for Adaptec 7770 based SCSI con-
trollers
esp(7D)
ESP SCSI Host Bus Adapter Driver
fas(7D)
FAS SCSI Host Bus Adapter Driver
fbio(7I)
frame buffer control operations
fd (7D)
drivers for floppy disks and floppy disk controllers
fdc(7D)
See fd (7D)
fdio(7I)
floppy disk control operations
ffb(7D)
24-bit UPA color frame buffer and graphics
accelerator
gld (7D)
Generic LAN Driver
glm(7D)
GLM SCSI Host Bus Adapter Driver
hdio(7I)
SMD and IPI disk control operations
hme (7D)
SUNW,hme Fast-Ethernet device driver
hsfs(7FS)
High Sierra & ISO 9660 CD-ROM filesystem
icmp(7P)
Internet Control Message Protocol
ICMP(7P)
See icmp(7P)
id(7D)
See ipi(7D)
ie(7D)
Intel 82586 Ethernet device driver
iee(7D)
Intel EtherExpress 16 Ethernet device driver
ieef(7D)
Intel EtherExpress Flash32/82596 Ethernet device
driver
if(7P)
See if_tcp(7P)
if_tcp(7P)
general properties of Internet Protocol network
interfaces
inet(7P)
Internet protocol family
ip(7P)
Internet Protocol
IP (7P)
See ip(7P)
ipd(7M)
See ppp(7M)
ipdcm(7M)
See ppp(7M)
ipdptp(7M)
See ppp(7M)
ipi(7D)
IPI driver
ipi3sc(7D)
See ipi(7D)
iprb(7D)
Intel 82557 (D100)-controlled Network Cards
is(7D)
See ipi(7D)
isdnio(7I)
ISDN interfaces
isp(7D)
ISP SCSI Host Bus Adapter Driver
iss(7D)
low-level module for Tricord System's SCSI host
bus adapter
kb(7M)
keyboard STREAMS module
kdmouse(7D)
built-in mouse device interface
keyboard(7D)
system console keyboard
kmem(7D)
See mem(7D)
kstat(7D)
kernel statistics driver
ksyms(7D)
kernel symbols
ldterm(7M)
standard STREAMS terminal line discipline module
le(7D)
Am7990 (LANCE) Ethernet device driver
lebuffer(7D)
See le(7D)
ledma(7D)
See le(7D)
leo(7D)
double-buffered 24-bit SBus color frame buffer and
graphics accelerator
llc1(7D)
Logical Link Control Protocol Class 1 Driver
lockstat(7D)
kernel lock statistics driver
lofs(7FS)
loopback virtual file system
log(7D)
interface to STREAMS error logging and event trac-
ing
logi(7D)
LOGITECH Bus Mouse device interface
lp(7D)
driver for parallel port
ltem(7D)
ANSI Layered Console Driver
m64(7D)
8-bit PCI color memory frame buffer
mcis(7D)
low-level module for IBM MicroChannel host bus
adapter
mcpp(7D)
ALM-2 Parallel Printer port driver
mcpzsa(7D)
ALM-2 Zilog 8530 SCC serial communications
driver
mem(7D)
physical or virtual memory
mic(7D)
Multi-interface Chip driver
mlx(7D)
low-level module for Mylex DAC960E EISA, Mylex
DAC960P/PD/PD-Ultra/PL PCI, and IBM
DMC960 Micro Channel host bus adapter series
msm(7D)
Microsoft Bus Mouse device interface
mt(7D)
tape interface
mtio(7I)
general magnetic tape interface
ncrs(7D)
low-level module for NCR 53C710, 53C810, 53C815,
53C820, and 53C825 host bus adapters
nee(7D)
Novell NE3200 Ethernet device Driver
nei(7D)
Novell NE2000, NE2000plus Ethernet device Driver
nfe (7D)
Compaq Netflex-2 Dualport Ethernet and
ENET/TR Drivers
null(7D)
the null file
openprom(7D)
PROM monitor configuration interface
pcelx(7D)
3COM EtherLink III PCMCIA Ethernet Adapter
pcfs(7FS)
DOS formatted file system
pcic(7D)
Intel i82365SL PC Card Interface Controller
pckt(7M)
STREAMS Packet Mode module
pcmem(7D)
PCMCIA memory card nexus driver
pcn(7D)
AMD PCnet Ethernet controller device driver
pcram(7D)
PCMCIA RAM memory card device driver
pcscsi(7D)
low-level module for the AMD PCscsi, PCscsi II,
PCnet-SCSI, and Qlogic QLA510 PCI-to-SCSI bus
adapters
pcser(7D)
PCMCIA serial card device driver
pe(7D)
Xircom Pocket Ethernet device driver
pfmod(7M)
STREAMS Packet Filter Module
pipemod(7M)
STREAMS pipe flushing module
pln(7D)
SPARCstorage Array SCSI Host Bus Adapter Driver
pm (7D)
power management driver
pmc(7D)
Platform Management Chip driver
pn(7D)
See ipi(7D)
ppp(7M)
STREAMS modules and drivers for the Point-to-
Point Protocol
ppp_diag(7M)
See ppp(7M)
ptem(7M)
STREAMS Pseudo Terminal Emulation module
ptm(7D)
STREAMS pseudo-tty master driver
pts(7D)
STREAMS pseudo-tty slave driver
pty (7D)
pseudo-terminal driver
qe(7D)
QEC/MACE Ethernet device driver
qec(7D)
QEC bus nexus device driver
quotactl(7I)
manipulate disk quotas
riles(7D)
device driver for the Racal Interlan ES-3210 Ether-
net Adapter
rns_smt(7D)
Rockwell Station Management driver
sad(7D)
STREAMS Administrative Driver
sbpro(7D)
Sound Blaster Pro, Sound Blaster 16, and Sound
Blaster AWE32 audio device driver
sd(7D)
driver for SCSI disk and CD-ROM devices
se(7D)
Siemens 82532 ESCC serial communications driver
se_hdlc(7D)
on-board high-performance serial HDLC interface
ses(7D)
SCSI enclosure services device driver
sesio(7I)
enclosure services device driver interface
sf(7D)
SOC+ FC-AL FCP Driver
smc(7D)
SMC 8003/8013/8216/8416 Ethernet device driver
smce(7D)
SMC 3032/EISA dual-channel Ethernet device
driver
smceu(7D)
SMC Elite32 Ultra (8232) Ethernet device driver
smcf(7D)
SMC Ether100 (9232) Ethernet device driver
soc(7D)
Serial Optical Controller (SOC) device driver
socal(7D)
Serial Optical Controller for Fibre Channel Arbi-
trated Loop (SOC+) device driver
sockio(7I)
ioctls that operate directly on sockets
ssd(7D)
driver for SPARCstorage Array and Fibre Channel
Arbitrated Loop disk devices
st(7D)
driver for SCSI tape devices
stc(7D)
Serial Parallel Communications driver for SBus
stp4020(7D)
STP 4020 PCMCIA Adapter
streamio(7I)
STREAMS ioctl commands
sxp(7D)
Rockwell 2200 SNAP Streams Driver
tcp(7P)
Internet Transmission Control Protocol
TCP (7P)
See tcp(7P)
tcx(7D)
24-bit SBus color memory frame buffer
termio (7I)
general terminal interface
termiox (7I)
extended general terminal interface
ticlts(7D)
loopback transport providers
ticots(7D)
See ticlts(7D)
ticotsord(7D)
See ticlts(7D)
timod(7M)
Transport Interface cooperating STREAMS module
tiqmouse(7D)
integrated mouse device interface
tirdwr(7M)
Transport Interface read/write interface STREAMS
module
tmpfs(7FS)
memory based filesystem
tpf(7D)
Platform Specific Module (PSM) for Tricord Sys-
tems Enterprise Server Models ES3000, ES4000 and
ES5000.
tr(7D)
IBM 16/4 Token Ring Network Adapter device
driver
trantor(7D)
low-level module for Trantor T348 Parallel SCSI
host bus adapter
ttcompat(7M)
V7, 4BSD and XENIX STREAMS compatibility
module
tty(7D)
controlling terminal interface
udp(7P)
Internet User Datagram Protocol
UDP(7P)
See udp(7P)
visual_io(7I)
Solaris VISUAL I/O control operations
volfs(7FS)
Volume Management file system
vuid2ps2(7M)
See vuidmice(7M)
vuid3ps2(7M)
See vuidmice(7M)
vuidm3p(7M)
See vuidmice(7M)
vuidm4p(7M)
See vuidmice(7M)
vuidm5p(7M)
See vuidmice(7M)
vuidmice(7M)
converts mouse protocol to Firm Events
wscons(7D)
workstation console
xd(7D)
disk driver for Xylogics 7053 SMD Disk Controller
xdc(7D)
See xd(7D)
xt(7D)
driver for Xylogics 472 1/2 inch tape controller
xy(7D)
disk driver for Xylogics 450 and 451 SMD Disk Con-
trollers
xyc (7D)
See xy(7D)
zero(7D)
source of zeroes
zs(7D)
Zilog 8530 SCC serial communications driver
zsh(7D)
On-board serial HDLC/SDLC interface
TCP(7P)

NAME

tcp, TCP - Internet Transmission Control Protocol

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_STREAM ,0);
t = t_open("/dev/tcp", O_RDWR );

DESCRIPTION

TCP is the virtual circuit protocol of the Internet protocol family. It provides reliable, flow-controlled, in order, two-way transmission of data. It is a byte-stream protocol layered above the Internet Protocol (IP), the Internet protocol family's internetwork datagram delivery protocol.
Programs can access TCP using the socket interface as a SOCK_STREAM socket type, or using the Transport Level Interface (TLI) where it supports the connection-oriented (T_COTS_ORD )service type.
TCP uses IP's host-level addressing and adds its own per-host collection of "port addresses." The endpoints of a TCP connection are identified by the combination of an IP address and a TCP port number. Although other protocols, such as the User Datagram Protocol (UDP), may use the same host and port address format, the port space of these protocols is distinct. See inet(7P) for details on the common aspects of addressing in the Internet protocol family.
Sockets utilizing TCP are either "active" or "passive". Active sockets initiate connections to passive sockets. Both types of sockets must have their local IP address and TCP port number bound with the bind(3N) system call after the socket is created. By default, TCP sockets are active. A passive socket is created by calling the listen(3N) system call after binding the socket with bind( ). This establishes a queueing parameter for the passive socket. After this, connections to the passive socket can be received with the accept(3N) system call. Active sockets use the connect(3N) call after binding to initiate connections.
By using the special value INADDR_ANY ,the local IP address can be left unspecified in the bind( ) call by either active or passive TCP sockets. This feature is usually used if the local address is either unknown or irrelevant. If left unspecified, the local IP address will be bound at connection time to the address of the network interface used to service the connection.
Once a connection has been established, data can be exchanged using the read (2)and write(2) system calls.
Under most circumstances, TCP sends data when it is presented. When outstanding data has not yet been acknowledged, TCP gathers small amounts of output to be sent in a single packet once an acknowledgement has been received. For a small number of clients, such as window systems that send a stream of mouse events which receive no replies, this packetization may cause significant delays. To circumvent this problem, TCP provides a socket-level boolean option, TCP_NODELAY .TCP_NODELAY is defined in <netinet/tcp.h>, and is set with setsockopt(3N) and tested with getsockopt(3N). The option level for the setsockopt( ) call is the protocol number for TCP, available from
getprotobyname(3N).
Another socket level option, SO_RCVBUF, can be used to control the window that TCP advertises to the peer. IP level options may also be used with TCP. See ip(7P).
TCP provides an urgent data mechanism, which may be invoked using the out-of-band provisions of send(3N). The caller may mark one byte as "urgent" with the MSG_OOB flag to send(3N). This sets an "urgent pointer" pointing to this byte in the TCP stream. The receiver on the other side of the stream is notified of the urgent data by a SIGURG signal. The SIOCATMARK ioctl( ) request returns a value indicating whether the stream is at the urgent mark. Because the system never returns data across the urgent mark in a single read (2)call, it is possible to advance to the urgent data in a simple loop which reads data, testing the socket with the SIOCATMARK ioctl( ) request, until it reaches the mark.
Incoming connection requests that include an IP source route option are noted, and the reverse source route is used in responding.
A checksum over all data helps TCP implement reliability. Using a window-based flow control mechanism that makes use of positive acknowledgements, sequence numbers, and a retransmission strategy, TCP can usually recover when datagrams are damaged, delayed, duplicated or delivered out of order by the underlying communication medium.
If the local TCP receives no acknowledgements from its peer for a period of time, as would be the case if the remote machine crashed, the connection is closed and an error is returned to the user. If the remote machine reboots or otherwise loses state information about a TCP connection, the connection is aborted and an error is returned to the user.
SunOS supports TCP Extensions for High Performance (RFC 1323), which includes the window scale and time stamp options, and Protection Against Wrap Around Sequence Numbers (PAWS).
Turn on the window scale option in one of the following ways:
  1. An application can set SO_SNDBUF or SO_RCVBUF size in the setsockopt( ) option to be larger than 64K. This must be done before the program calls listen ( ) or connect( ), because the window scale option is negotiated when the connection is established. Once the connection has been made, it is too late to increase the send or receive window beyond the default TCP limit of 64K.

  2. For all applications, use ndd(1M) to modify the configuration parameter tcp_wscale_always. If tcp_wscale_always is set to 1 ,the window scale option will always be set when connecting to a remote system. If tcp_wscale_always is 0, the window scale option will be set only if the user has requested a send or receive window larger than 64K. The default value of tcp_wscale_always is 0 .

  3. Regardless of the value of tcp_wscale_always, the window scale option will always be included in a connect acknowledgement if the connecting system has used the option.

Turn on the time stamp option in the following way:
Use ndd to modify the configuration parameter tcp_tstamp_always. If tcp_tstamp_always is 1 ,the time stamp option will always be set when connecting to a remote machine. If tcp_tstamp_always is 0 ,the time stamp option will not be set when connecting to a remote system. The default for tcp_tstamp_always is 0 .
Regardless of the value of tcp_tstamp_always, the time stamp option will always be included in a connect acknowledgement (and all succeeding packets) if the connecting system has used the time stamp option.
Use the following procedure to turn on the time stamp option only when the window scale option is in effect:
Use ndd to modify the configuration parameter tcp_tstamp_if_wscale. Setting tcp_tstamp_if_wscale to 1 will cause the time stamp option to be set when connecting to a remote system, if the window scale option has been set. If tcp_tstamp_if_wscale is 0 ,the time stamp option will not be set when connecting to a remote system. The default for tcp_tstamp_if_wscale is 0 .
Protection Against Wrap Around Sequence Numbers (PAWS) is always used when the time stamp option is set.

SEE ALSO

ndd(1M), read (2),write(2), accept(3N), bind(3N), connect(3N), getprotobyname(3N), getsockopt(3N), listen(3N), send(3N), inet(7P), ip(7P)
Postel, Jon, Transmission Control Protocol - DARPA Internet Program Protocol Specification, RFC 793, Network Information Center, SRI International, Menlo Park, Calif., September 1981.
Jacobson, V., Braden, R., and Borman, D., TCP Extensions for High Performance, RFC 1323, May 1992.

DIAGNOSTICS

A socket operation may fail if:
EISCONN
A connect( ) operation was attempted on a socket on which a connect( ) operation had already been performed.
ETIMEDOUT
A connection was dropped due to excessive retransmissions.
ECONNRESET
The remote peer forced the connection to be closed (usually
because the remote machine has lost state information about the connection due to a crash).
ECONNREFUSED
The remote peer actively refused connection establishment (usually because no process is listening to the port).
EADDRINUSE
A bind( ) operation was attempted on a socket with a network address/port pair that has already been bound to another socket.
EADDRNOTAVAIL
A bind( ) operation was attempted on a socket with a network address for which no network interface exists.
EACCES
A bind( ) operation was attempted with a "reserved" port number and the effective user ID of the process was not the privileged user.
ENOBUFS
The system ran out of memory for internal data structures.
UDP(7P)

NAME

udp, UDP - Internet User Datagram Protocol

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_DGRAM ,0);
t = t_open("/dev/udp", O_RDWR );

DESCRIPTION

UDP is a simple datagram protocol which is layered directly above the Internet Protocol (IP). Programs may access UDP using the socket interface, where it supports the SOCK_DGRAM socket type, or using the Transport Level Interface (TLI), where it supports the connectionless (T_CLTS) service type.
Within the socket interface, UDP is normally used with the sendto( ), sendmsg( ), recvfrom( ), and recvmsg( ) calls (see send(3N) and recv(3N)). If the connect(3N) call is used to fix the destination for future packets, then the recv(3N) or read (2)and send(3N) or write(2) calls may be used.
UDP address formats are identical to those used by the Transmission Control Protocol (TCP). Like TCP, UDP uses a port number along with an IP address to identify the endpoint of communication. The UDP port number space is separate from the TCP port number space (that is, a UDP port may not be "connected" to a TCP port). The bind(3N) call can be used to set the local address and port number of a UDP socket. The local IP address may be left unspecified in the bind( ) call by using the special value INADDR_ANY. If the bind( ) call is not done, a local IP address and port number will be assigned to the endpoint when the first packet is sent. Broadcast packets may be sent (assuming the underlying network supports this) by using a reserved "broadcast address"; This address is network interface dependent. Broadcasts may only be sent by the privileged user.
Options at the IP level may be used with UDP; see ip(7P).
There are a variety of ways that a UDP packet can be lost or corrupted, including a failure of the underlying communication mechanism. UDP implements a checksum over the data portion of the packet. If the checksum of a received packet is in error, the packet will be dropped with no indication given to the user. A queue of received packets is provided for each UDP socket. This queue has a limited capacity. Arriving datagrams which will not fit within its high-water capacity are silently discarded.
UDP processes Internet Control Message Protocol (ICMP) error messages received in response to UDP packets it has sent. See icmp(7P). ICMP "source quench" messages are ignored. ICMP "destination unreachable," "time exceeded" and "parameter problem" messages disconnect the socket from its peer so that subsequent attempts to send packets using that socket will return an error. UDP will not guarantee that packets are delivered in the order they were sent. As well, duplicate packets may be generated in the communication process.

SEE ALSO

read (2),write(2), bind(3N), connect(3N), recv(3N), send(3N), icmp(7P), inet(7P), ip(7P), tcp(7P)
Postel, Jon, User Datagram Protocol, RFC 768, Network Information Center, SRI International, Menlo Park, Calif., August 1980

DIAGNOSTICS

A socket operation may fail if:
EISCONN
A connect( ) operation was attempted on a socket on which a connect( ) operation had already been performed, and the socket could not be successfully disconnected before making the new connection.
EISCONN
A sendto( ) or sendmsg( ) operation specifying an address to which the message should be sent was attempted on a socket on which a connect( ) operation had already been performed.
ENOTCONN
A send( ) or write( ) operation, or a sendto( ) or sendmsg( ) operation not specifying an address to which the message should be sent, was attempted on a socket on which a connect( ) operation had not already been performed.
EADDRINUSE
A bind( ) operation was attempted on a socket with a network address/port pair that has already been bound to another socket.
EADDRNOTAVAIL
A bind( ) operation was attempted on a socket with a network address for which no network interface exists.
EINVAL
A sendmsg( ) operation with a non-NULL msg_accrights was attempted.
EACCES
A bind( ) operation was attempted with a "reserved" port number and the effective user ID of the process was not the privileged user.
ENOBUFS
The system ran out of memory for internal data structures.
adp(7D)

NAME

adp - low-level module for Adaptec 7870/7871/7872/7880/7881/7882-based SCSI controllers

SYNOPSIS

adp@reg

DESCRIPTION

The adp module provides low-level interface routines between the common disk/tape I/O system and SCSI (Small Computer System Interface) controllers based on the Adaptec AIC-7870P and AIC-7880P SCSI chips. These controllers include the Adaptec 2940, 2940W, 2940U, 2940UW, 3940, and 3940W, as well as motherboards with embedded AIC- 7870P and AIC-7880P SCSI chips.
The adp module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Autoconfiguration code determines if the adapter is present at the configured address and what types of devices are attached to the adapter.
The device address, reg, is derived from bits 3-7 of the PCI device number.

FILES

/kernel/drv/adp.conf
configuration file for the adp driver. There are no user-
configurable options in this file.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
aha(7D)

NAME

aha - low-level module for Adaptec 154x ISA host bus adapters

DESCRIPTION

The aha module provides low-level interface routines between the common disk/tape I/O subsystem and the Adaptec ISA bus master 154x SCSI (Small Computer System Interface) controllers. The aha module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and what types of devices are attached to it.

Board Configuration and Auto

The driver attempts to initialize itself in accordance with the information found in the configuration file, /kernel/drv/aha.conf. A list of the relevant user configurable items follows.

Configuration

dma speed "dmaspeed=0"
bus on time "buson=5"
bus off time "busoff=9"
The I/O port is the ISA bus I/O address used for communication with the adapter. The direct memory access (DMA) channel should be set to the manufacturer's default of 5 for the primary adapter. The DMA speed, bus on time, and bus off times may be set for optimum performance with each ISA motherboard. Refer to the Adaptec AHA-1540/1542 User's Manual for instructions. All jumpers on the board should be set (or verified) to conform with the configuration file.
The 154xC and the 154xCF should be set to default values. Specifically, disable BIOS support for drives with more than 1024 cylinders and more than two BIOS drives. Make sure that the DMA transfer speed does not exceed the capabilities of the motherboard: most can not be run faster than the default 5.7.
The default configurations described in the Adaptec AHA-1540/1542 User's Manual should be used for standard configurations of the system. If more than one board is to be used in a single system, each must at least occupy a different set of address ranges and use a different DMA channel. Use of a different interrupt level for each board is required.
The default listing of the configuration file is as follows:
dmaspeed=0 buson=5 busoff=5
flow_control="dmult" queue="qsort" disk="scdk" tape="sctp";
After installation, 154x controllers may be jumpered for any of the I/O address, IRQ, and DMA channel combinations supported by the hardware, provided that the parameters do not conflict with other devices on the system.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
aic(7D)

NAME

aic - low-level module for Adaptec AIC-6360 based ISA host bus adapters

SYNOPSIS

aic@reg

DESCRIPTION

The aic module provides low-level interface routines between the common disk/tape I/O subsystem and AIC-6360 based SCSI (Small Computer System Interface) bus controllers. It also provides support for the Adaptec AHA-1510A, AHA-1520A, and AHA-1522A SCSI controllers. It supports the AIC-6360 SCSI controller on the Sound Blaster 16 SCSI-2 board but does not support the audio functions -- the sbpro(7D) driver provides these capabilities. Note that the AHA-1510A board and the SCSI port on the Sound Blaster 16 SCSI-2 board can only be used as a secondary controller -- not a primary (boot) controller.
The aic module can be configured for disk and streaming tape support for one or two host adapter boards, each of which must be the sole initiator on a SCSI bus. Autoconfiguration code determines if the adapter is present at the configured address and determines what types of devices are attached to the adapter.

CONFIGURATION

The driver attempts to initialize itself using the information found in the configuration file, aic.conf.
If multiple boards are configured in a single system, each board must occupy a different I/O base address in the system I/O address space. Each board must also be assigned a different IRQ level.
The AHA-1522 or AHA-1520A controller can be used as a primary boot controller only at I/O base address 0x340 (unless special BIOS from Adaptec is procured). Therefore, if a system installation is performed using a SCSI device (such as a CD-ROM drive) connected to one of these adapters, the adapter must be configured with I/O base address 0x340 . (The adapter BIOS supports booting from this address only.)
Refer to the AHA-1520A/1522A AT-to-SCSI Host Adapters Installation Guide provided with the controller for instructions on installation of the adapter and the valid jumper settings. The default jumper configuration described in the AHA-1520A/1522A AT-to-SCSI Host Adapters Installation Guide is the recommended configuration for the controller.

FILES

/kernel/drv/aic.conf
aic device driver configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

driver.conf(4), attributes(5), sysbus(4), sbpro(7D)

NOTES

The aic driver does not support direct memory access (DMA).
The aic driver does not support SCSI timeouts.
arp(7P)

NAME

arp, ARP - Address Resolution Protocol

SYNOPSIS

#include <sys/fcntl.h>
#include <sys/socket.h>
#include <net/if_arp.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_DGRAM ,0);
d = open ("/dev/arp", oflag);

DESCRIPTION

ARP is a protocol used to map dynamically between Internet Protocol (IP) and 10Mb/s Ethernet addresses. It is used by all the 10Mb/s Ethernet datalink providers (interface drivers) and it can be used by other datalink providers that support broadcast (such as FDDI and Token Ring). ARP is not specific to the Internet Protocol but this implementation supports only that network layer protocol.
ARP caches IP-to-Ethernet address mappings. When an interface requests a mapping for an address not in the cache, ARP queues the message that requires the mapping and broadcasts a message on the associated network requesting the address mapping. If a response is provided, the new mapping is cached and any pending message is transmitted. ARP will queue at most four packets while waiting for a mapping request to be responded to; only the four most recently transmitted packets are kept.

APPLICATION PROGRAMMING

The STREAMS device /dev/arp is not a Transport Level Interface (TLI) transport provider and may not be used with the TLI interface.

INTERFACE

To facilitate communications with systems which do not use ARP, ioctl( ) requests are provided to enter and delete entries in the IP-to-Ethernet tables.
#include <sys/sockio.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_arp.h>
struct arpreq arpreq;
ioctl(s, SIOCSARP ,(caddr_t)&arpreq);
ioctl(s, SIOCGARP ,(caddr_t)&arpreq);
ioctl(s, SIOCDARP ,(caddr_t)&arpreq);
Each ioctl( ) request takes the same structure as an argument. SIOCSARP sets an ARP entry, SIOCGARP gets an ARP entry, and SIOCDARP deletes an ARP entry. These ioctl( ) requests may be applied to any Internet family socket descriptor s, or to a descriptor for the ARP device, but only by the privileged user.
The arpreq structure contains:
/*
* ARP ioctl request
* /
struct arpreq {
        struct sockaddr   arp_pa;             /* protocol address * /
        struct sockaddr   arp_ha;             /* hardware address * /
        int               arp_flags;           /* flags * /
};
/* arp_flags field values * /
#define ATF_COM             0x2 /* completed entry (arp_ha valid) * /
#define ATF_PERM            0x4 /* permanent entry * /
#define ATF_PUBL            0x8 /* publish (respond for other host) * /
#define ATF_USETRAILERS 0x10 /* send trailer packets to host * /
The address family for the arp_pa sockaddr must be AF_INET; for the arp_ha sockaddr it must be AF_UNSPEC. The only flag bits that may be written are ATF_PUBL and ATF_USETRAILERS. ATF_PERM makes the entry permanent if the ioctl( ) request succeeds. The peculiar nature of the ARP tables may cause the ioctl( ) request to fail if too many permanent IP addresses hash to the same slot. ATF_PUBL specifies that the ARP code should respond to ARP requests for the indicated host coming from other machines. This allows a host to act as an " ARPserver", which may be useful in convincing an ARP-only machine to talk to a non-ARP machine.
ARP is also used to negotiate the use of trailer IP encapsulations; trailers are an alternate encapsulation used to allow efficient packet alignment for large packets despite variablesized headers. Hosts that wish to receive trailer encapsulations so indicate by sending gratuitous ARP translation replies along with replies to IP requests; they are also sent in reply to IP translation replies. The negotiation is thus fully symmetrical, in that either or both hosts may request trailers. The ATF_USETRAILERS flag is used to record the receipt of such a reply, and enables the transmission of trailer packets to that host.
ARP watches passively for hosts impersonating the local host (that is, a host which responds to an ARP mapping request for the local host's address).

SEE ALSO

arp (1M),ifconfig (1M),if_tcp(7P), inet(7P)
Plummer, Dave, ``An Ethernet Address Resolution Protocol -or- Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware,'' RFC 826, Network Information Center, SRI International, Menlo Park, Calif., November 1982.
Leffler, Sam, and Michael Karels, ``Trailer Encapsulations,'' RFC 893, Network Information Center, SRI International, Menlo Park, Calif., April 1984.

DIAGNOSTICS

IP: Hardware address '%x:%x:%x:%x:%x:%x' trying to be our address '%d.%d.%d.%d'!
Duplicate IP address. ARP has discovered another host on the local network which responds to mapping requests for the Internet address of this system.
IP: Proxy ARP problem? Hardware address '%x:%x:%x:%x:%x:%x' thinks it is
'%d.%d.%d.%d'
This message will appear if arp (1M)has been used to create a published entry and some other host on the local network responds to mapping requests for the published arp entry.
asy(7D)

NAME

asy - asynchronous serial port driver

SYNOPSIS

#include <fcntl.h>
#include <sys/termios.h>
open("/dev/ttynn", mode);
open("/dev/ttydn", mode);
open("/dev/cuan", mode);

DESCRIPTION

The asy module is a loadable STREAMS driver that provides basic support for the standard UARTS that use Intel-8250, National Semiconductor-16450/16550 hardware, together with basic asynchronous communication support. The driver supports those termio (7I)device control functions specified by flags in the c_cflag word of the termios structure and by the IGNBRK ,IGNPAR ,PARMRK ,or INPCK flags in the c_iflag word of the termios structure. All other termio (7I)functions must be performed by STREAMS modules pushed atop the driver. When a device is opened, the ldterm(7M) and ttcompat(7M) STREAMS modules are automatically pushed on top of the stream, providing the standard termio (7I)interface.
The character-special devices /dev/tty00 and /dev/tty01 are used to access the two standard serial ports (COM1 and COM2) on an x86 based system. The asy driver supports up to four serial ports, including the standard ports. These ttynn devices have minor device numbers in the range 00-03.
By convention these same devices may be given names of the form /dev/ttydn, where n denotes which line is to be accessed. Such device names are typically used to provide a logical access point for a dial-in line being used with a modem.
To allow a single tty line to be connected to a modem and used for both incoming and outgoing calls, a special feature, controlled by the minor device number, is available. By accessing character-special devices with names of the form /dev/cuan it is possible to open a port without the Carrier Detect signal being asserted, either through hardware or an equivalent software mechanism. These devices are commonly known as dial-out lines.

APPLICATION PROGRAMMING

Once a /dev/cuan line is opened, the corresponding tty, or ttyd line cannot be opened until the /dev/cuan line is closed; a blocking open will wait until the /dev/cuan line is closed (which will drop Data Terminal Ready, after which Carrier Detect will usually drop as well) and carrier is detected again, and a non-blocking open will return an error. Also, if the /dev/ttydn line has been opened successfully (usually only when carrier is recognized on the modem) the corresponding /dev/cuan line can not be opened. This allows a modem to be attached to, for example, /dev/ttyd0 (renamed from /dev/tty00) and used for dial-in (by enabling the line for login in /etc/inittab) and also used for dialout (by tip(1) or uucp(1C)) as /dev/cua0 when no one is logged in on the line.

INTERFACE


IOCTLS

The standard set of termio ioctl( ) calls are supported by asy .
Breaks can be generated by the TCSBRK ,TIOCSBRK ,and TIOCCBRK ioctl( ) calls.
The input and output line speeds may be set to any of the speeds supported by termio . The speeds cannot be set independently; when the output speed is set, the input speed is set to the same speed.

ERRORS

An open( ) will fail if:
ENXIO
The unit being opened does not exist.
EBUSY
The dial-out device is being opened and the dial-in device is already open, or the dial-in device is being opened with a no-delay open and the dial-out device is already open.
EBUSY
The unit has been marked as exclusive-use by another process with a TIOCEXCL ioctl( ) call.
EINTR
The open was interrupted by the delivery of a signal.

FILES

/dev/tty[00-03]
hardwired tty lines
/dev/ttyd[0-3]
dial-in tty lines
/dev/cua[0-3]
dial-out tty lines
/platform/i86pc/kernel/drv/asy.conf
asy configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

tip(1), uucp(1C), ioctl(2), open(2), termios(3), attributes(5), ldterm(7M), termio (7I), ttcompat(7M)

DIAGNOSTICS

asy n: silo overflow.
The hardware overrun occurred before the input character could be serviced.
asy n: ring buffer overflow.
The driver's character input ring buffer overflowed before it could be serviced.
ata(7D)

NAME

ata - AT attachment disk driver

SYNOPSIS

ata@1,ioaddr

DESCRIPTION

The ata driver supports disk and CD-ROM interfaces conforming to the AT Attachment specification including IDE interfaces. It excludes the MFM, RLL, ST506, and ST412 interfaces. Support is provided for CD_ROM drives that conform to the Small Form Factor (SFF) ATA Packet Interface (ATAPI) specification: SFF-8020 revision 1.2.

CONFIGURATION

The driver initializes itself in accordance with the information found in the configuration file ata.conf (see below). The only user configurable items in this file are:
drive0_block_factor
drive1_block_factor
ATA controllers support some amount of buffering (blocking). The purpose is to interrupt the host when an entire buffer full of data has been read or written instead of using an interrupt for each sector. This reduces interrupt overhead and significantly increases throughput. The driver interrogates the controller to find the buffer size. Some controllers hang when buffering is used, so the values in the configuration file are used by the driver to reduce the effect of buffering (blocking). The values presented may be chosen from 0x1 ,0x2 ,0x4 ,0x8 and 0x10 .
The values as shipped are set to 0x1 ,and they can be tuned to increase performance.
If your controller hangs when attempting to use higher block factors, you may be unable to reboot the system. For x86 based systems, it is recommended that the tuning be carried out using a duplicate of the /platform/i86pc/kernel directory subtree. This will ensure that a bootable kernel subtree exists in the event of a failed test.
max_transfer
This value controls the size of individual requests for consecutive disk sectors. The value may range from 0x1 to 0x100 . Higher values yield higher throughput. The system is shipped with a value of 0x100 ,which probably should not be changed.

EXAMPLES

The following is an example of an ata.conf configuration file.
# for higher performance - set block factor to 16
        drive0_block_factor=0x1 drive1_block_factor=0x1
        max_transfer=0x100
        flow_control="dmult" queue="qsort" disk="dadk" ;

x86 FILES

/platform/i86pc/kernel/drv/ata
The device file.
/platform/i86pc/kernel/drv/ata.conf
The configuration file.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), aha(7D), cmdk(7D), dpt(7D), eha(7D)
audio(7I)

NAME

audio - generic audio device interface

OVERVIEW

The audio interface described below is an uncommitted interface and may be replaced in the future.
An audio device is used to play and/or record a stream of audio data. Since a specific audio device may not support all of the functionality described below, refer to the device-specific manual pages for a complete description of each hardware device. An application can use the AUDIO_GETDEV ioctl(2) to determine the current audio hardware associated with /dev/audio.

AUDIO FORMATS

Digital audio data represents a quantized approximation of an analog audio signal waveform. In the simplest case, these quantized numbers represent the amplitude of the input waveform at particular sampling intervals. In order to achieve the best approximation of an input signal, the highest possible sampling frequency and precision should be used. However, increased accuracy comes at a cost of increased data storage requirements. For instance, one minute of monaural audio recorded in .-law format at 8 KHz requires nearly 0.5 megabytes of storage, while the standard Compact Disc audio format (stereo 16-bit linear PCM data sampled at 44.1 KHz) requires approximately 10 megabytes per minute.
Audio data may be represented in several different formats. An audio device's current audio data format can be determined by using the AUDIO_GETINFO ioctl described below.
An audio data format is characterized in the audio driver by four parameters: Sample Rate, Encoding, Precision, and Channels. Refer to the device-specific manual pages for a list of the audio formats that each device supports. In addition to the formats that the audio device supports directly, other formats provide higher data compression. Applications may convert audio data to and from these formats when recording or playing.

Sample Rate

Sample rate is a number that represents the sampling frequency (in samples per second) of the audio data.

Encodings

An encoding parameter specifies the audio data representation. .-law encoding (pronounced mew-law) corresponds to CCITT G.711, and is the standard for voice data used by telephone companies in the United States, Canada, and Japan. A-law encoding is also part of G.711, and is the standard encoding for telephony elsewhere in the world. A-law and .-law audio data are sampled at a rate of 8000 samples per second with 12-bit precision, with the data compressed to 8-bit samples. The resulting audio data quality is equivalent to that of standard analog telephone service.
Linear Pulse Code Modulation (PCM) is an uncompressed audio format in which sample values are directly proportional to audio signal voltages. Each sample is a 2's complement number that represents a positive or negative amplitude.

Precision

Precision indicates the number of bits used to store each audio sample. For instance, .-law and A-law data are stored with 8-bit precision. PCM data may be stored at various precisions, though 16-bit PCM is most common.

Channels

Multiple channels of audio may be interleaved at sample boundaries. A sample frame consists of a single sample from each active channel. For example, a sample frame of stereo 16-bit PCM data consists of 2 16-bit samples, corresponding to the left and right channel data.

DESCRIPTION

The device /dev/audio is a device driver that dispatches audio requests to the appropriate underlying audio device driver. The audio driver is implemented as a STREAMS driver. In order to record audio input, applications open(2) the /dev/audio device and read data from it using the read (2)system call. Similarly, sound data is queued to the audio output port by using the write(2) system call. Device configuration is performed using the ioctl(2) interface.
As some systems may contain more than one audio device, application writers are encouraged to query the AUDIODEV environment variable. If this variable is present in the environment, its value should identify the path name of the default audio device.

Opening the Audio Device

The audio device is treated as an exclusive resource - only one process can open the device at a time. However, two processes may simultaneously access the device: if one opens it read-only, then another may open it write-only.
When a process cannot open /dev/audio because the requested access mode is busy:
if either the O_NDELAY or O_NONBLOCK flag are set in the open( ) oflag argument, then -1 is immediately returned, with errno set to EBUSY . if neither the O_NDELAY nor the O_NONBLOCK flag are set, then open( ) hangs until the device is available or a signal is delivered to the process, in which case a -1 is returned with errno set to EINTR .This allows a process to block in the open call, while waiting for the audio device to become available.
Upon the initial open( ) of the audio device, the driver will reset the data format of the device to the default state of 8-bit, 8Khz, mono .-law data. If the device is already open and a different audio format has been set, this will not be possible. Audio applications should explicitly set the encoding characteristics to match the audio data requirements, rather than depend on the default configuration.
Since the audio device grants exclusive read or write access to a single process at a time, long-lived audio applications may choose to close the device when they enter an idle state and reopen it when required. The play.waiting and record.waiting flags in the audio information structure (see below) provide an indication that another process has requested access to the device. For instance, a background audio output process may choose to relinquish the audio device whenever another process requests write access.

Recording Audio Data

The read( ) system call copies data from the system buffers to the application. Ordinarily, read( ) blocks until the user buffer is filled. The I_NREAD ioctl (see streamio(7I)) may be used to determine the amount of data that may be read without blocking. The device may alternatively be set to a non-blocking mode, in which case read( ) completes
immediately, but may return fewer bytes than requested. Refer to the read (2)manual page for a complete description of this behavior.
When the audio device is opened with read access, the device driver immediately starts buffering audio input data. Since this consumes system resources, processes that do not record audio data should open the device write-only (O_WRONLY ).
The transfer of input data to STREAMS buffers may be paused (or resumed) by using the AUDIO_SETINFO ioctl to set (or clear) the record.pause flag in the audio information structure (see below). All unread input data in the STREAMS queue may be discarded by using the I_FLUSH STREAMS ioctl (see streamio(7I)). When changing record parameters, the input stream should be paused and flushed before the change, and resumed afterward. Otherwise, subsequent reads may return samples in the old format followed by samples in the new format. This is particularly important when new parameters result in a changed sample size.
Input data can accumulate in STREAMS buffers very quickly. At a minimum, it will accumulate at 8000 bytes per second for 8-bit, 8 KHz, mono, .-law data. If the device is configured for 16-bit linear or higher sample rates, it will accumulate even faster. If the application that consumes the data cannot keep up with this data rate, the STREAMS queue may become full. When this occurs, the record.error flag is set in the audio information structure and input sampling ceases until there is room in the input queue for additional data. In such cases, the input data stream contains a discontinuity. For this reason, audio recording applications should open the audio device when they are prepared to begin reading data, rather than at the start of extensive initialization.

Playing Audio Data

The write( ) system call copies data from an applications buffer to the STREAMS output queue. Ordinarily, write( ) blocks until the entire user buffer is transferred. The device may alternatively be set to a non-blocking mode, in which case write( ) completes immediately, but may have transferred fewer bytes than requested (see write(2)).
Although write( ) returns when the data is successfully queued, the actual completion of audio output may take considerably longer. The AUDIO_DRAIN ioctl may be issued to allow an application to block until all of the queued output data has been played. Alternatively, a process may request asynchronous notification of output completion by writing a zero-length buffer (end-of-file record) to the output stream. When such a buffer has been processed, the play.eof flag in the audio information structure (see below) is incremented.
The final close(2) of the file descriptor hangs until audio output has drained. If a signal interrupts the close( ), or if the process exits without closing the device, any remaining data queued for audio output is flushed and the device is closed immediately.
The conversion of output data may be paused (or resumed) by using the AUDIO_SETINFO ioctl to set (or clear) the play.pause flag in the audio information structure. Queued output data may be discarded by using the I_FLUSH STREAMS ioctl.
Output data will be played from the STREAMS buffers at a rate of at least 8000 bytes per second for .-law or A-law data (faster for 16-bit linear data or higher sampling rates). If the output queue becomes empty, the play.error flag is set in the audio information
structure and output is stopped until additional data is written. If an application attempts to write a number of bytes that is not a multiple of the current sample frame size, an error will be generated and the device will need to be closed before any future writes will succeed.

Asynchronous I/O

The I_SETSIG STREAMS ioctl enables asynchronous notification, through the SIGPOLL signal, of input and output ready conditions. The O_NONBLOCK flag may be set using the F_SETFL fcntl(2) to enable non-blocking read( ) and write( ) requests. This is normally sufficient for applications to maintain an audio stream in the background.

Audio Control Pseudo-Device

It is sometimes convenient to have an application, such as a volume control panel, modify certain characteristics of the audio device while it is being used by an unrelated process. The /dev/audioctl pseudo-device is provided for this purpose. Any number of processes may open /dev/audioctl simultaneously. However, read( ) and write( ) system calls are ignored by /dev/audioctl. The AUDIO_GETINFO and AUDIO_SETINFO ioctl commands may be issued to /dev/audioctl to determine the status or alter the behavior of /dev/audio. Note: In general, the audio control device name is constructed by appending the letters "ctl" to the path name of the audio device.

Audio Status Change Notification

Applications that open the audio control pseudo-device may request asynchronous notification of changes in the state of the audio device by setting the S_MSG flag in an I_SETSIG STREAMS ioctl. Such processes receive a SIGPOLL signal when any of the following events occur:
An AUDIO_SETINFO ioctl has altered the device state.
An input overflow or output underflow has occurred.
An end-of-file record (zero-length buffer) has been processed on output. An open( ) or close( ) of /dev/audio has altered the device state. An external event (such as speakerbox volume control) has altered the device state.

IOCTLS

Audio Information Structure

The state of the audio device may be polled or modified using the AUDIO_GETINFO and AUDIO_SETINFO ioctl commands. These commands operate on the audio_info structure as defined, in <sys/audioio.h>, as follows:
/* This structure contains state information for audio device
 IO streams * /
struct audio_prinfo {
        /* The following values describe the audio data encoding * /
     uint_t  sample_rate;   /* samples per second * /
     uint_t  channels;      /* number of interleaved channels * /
     uint_t  precision;     /* number of bits per sample * /
     uint_t  encoding;      /* data encoding method * /
/* The following values control audio device configuration * /
     uint_t  gain;          /* volume level * /
     uint_t  port;          /* selected I/O port * /
     uint_t  buffer_size;   /* I/O buffer size * /
/* The following values describe the current device state * /
     uint_t  samples;       /* number of samples converted * /
     uint_t  eof;           /* End Of File counter (play only) * /
     uchar_t pause;         /* non-zero if paused, zero to resume * /
     uchar_t error;         /* non-zero if overflow/underflow * /
     uchar_t waiting;       /* non-zero if a process wants access * /
     uchar_t balance;       /* stereo channel balance * /
/* The following values are read-only device state flags * /
     uchar_t open;          /* non-zero if open access granted * /
     uchar_t active;        /* non-zero if I/O active * /
     uint_t  avail_ports;   /* available I/O ports * /
} audio_prinfo_t;
/* This structure is used in AUDIO_GETINFO and AUDIO_SETINFO ioctl
 commands * /
typedef struct audio_info {
     audio_prinfo_t record;        /* input status information * /
     audio_prinfo_t play;          /* output status information * /
     uint_t         monitor_gain;  /* input to output mix * /
     uchar_t        output_muted; /* non-zero if output muted * /
} audio_info_t;
/* Audio encoding types * /
#define AUDIO_ENCODING_ULAW              (1)     /* u-law encoding * /
#define AUDIO_ENCODING_ALAW              (2)     /* A-law encoding * /
#define AUDIO_ENCODING_LINEAR            (3)     /* Linear PCM encoding * /
/* These ranges apply to record, play, and monitor gain values * /
#define AUDIO_MIN_GAIN                   (0)     /* minimum gain value * /
#define AUDIO_MAX_GAIN                   (255)   /* maximum gain value * /
/* These values apply to the balance field to adjust channel gain values * /
#define AUDIO_LEFT_BALANCE               (0)     /* left channel only * /
#define AUDIO_MID_BALANCE                (32)    /* equal left/right balance * /
#define AUDIO_RIGHT_BALANCE              (64)    /* right channel only * /
/* Define some convenient audio port names (for port and avail_ports) * /
/* output ports (several might be enabled at once) * /
#define AUDIO_SPEAKER                    (0x01)  /* output to built-in speaker * /
#define AUDIO_HEADPHONE                  (0x02)  /* output to headphone jack * /
#define AUDIO_LINE_OUT                   (0x04)  /* output to line out * /
/* input ports (usually only one may be enabled at a time) * /
#define AUDIO_MICROPHONE                 (0x01)  /* input from microphone * /
#define AUDIO_LINE_IN                    (0x02)  /* input from line in * /

#define                                  MAX_AUDIO_DEV_LEN(16)
/* Parameter for the AUDIO_GETDEV ioctl * /
typedef struct audio_device {
     char name[MAX_AUDIO_DEV_LEN];
     char version[MAX_AUDIO_DEV_LEN];
     char config[MAX_AUDIO_DEV_LEN];
} audio_device_t;
The play.gain and record.gain fields specify the output and input volume levels. A value of AUDIO_MAX_GAIN indicates maximum volume. Audio output may also be temporarily muted by setting a non-zero value in the output_muted field. Clearing this field restores
audio output to the normal state. Most audio devices allow input data to be monitored by mixing audio input onto the output channel. The monitor_gain field controls the level of this feedback path.
The play.port field controls the output path for the audio device. It can be set to either AUDIO_SPEAKER (built-in speaker), AUDIO_HEADPHONE (headphone jack), or AUDIO_LINE_OUT (line-out port). For some devices, it may be set to a combination of these ports. The play.avail_ports field returns the set of output ports that are currently accessible. The input ports can be either AUDIO_MICROPHONE or AUDIO_LINE_IN . The record.avail_ports field returns the set of input ports that are currently accessible.
The play.balance and record.balance fields are used to control the volume between the left and right channels when manipulating stereo data. When the value is set between AUDIO_LEFT_BALANCE and AUDIO_MID_BALANCE ,the right channel volume will be reduced in proportion to the balance value. Conversely, when balance is set between AUDIO_MID_BALANCE and AUDIO_RIGHT_BALANCE ,the left channel will be proportionally reduced.
The play.pause and record.pause flags may be used to pause and resume the transfer of data between the audio device and the STREAMS buffers. The play.error and record.error flags indicate that data underflow or overflow has occurred. The play.active and record.active flags indicate that data transfer is currently active in the corresponding direction.
The play.open and record.open flags indicate that the device is currently open with the corresponding access permission. The play.waiting and record.waiting flags provide an indication that a process may be waiting to access the device. These flags are set automatically when a process blocks on open( ), though they may also be set using the AUDIO_SETINFO ioctl command. They are cleared only when a process relinquishes access by closing the device.
The play.samples and record.samples fields are initialized, at open( ), to zero and increment each time a data sample is copied to or from the associated STREAMS queue. Some audio drivers may be limited to counting buffers of samples, instead of single samples for the samples accounting. For this reason, applications should not assume that the samples fields contain a perfectly accurate count. The play.eof field increments whenever a zerolength output buffer is synchronously processed. Applications may use this field to detect the completion of particular segments of audio output.
The record.buffer_size field controls the amount of input data that is buffered in the device driver during record operations. Applications that have particular requirements for low latency should set the value appropriately. Note however that smaller input buffer sizes may result in higher system overhead. The value of this field is specified in bytes and drivers will constrain it to be a multiple of the current sample frame size. Some drivers may place other requirements on the value of this field. Refer to the audio device-specific manual page for more details. If an application changes the format of the audio device and does not modify the record.buffer_size field, the device driver may use a default value to compensate for the new data rate. Therefore, if an application wishes to modify this field, it should modify it during or after the format change itself, not before. The
record.buffer_size field may be modified only on the /dev/audio device by processes that have it opened for reading. The play.buffer_size field is currently not supported.
The audio data format is indicated by the sample_rate, channels, precision, and encoding fields. The values of these fields correspond to the descriptions in the AUDIO FORMATS section above. Refer to the audio device-specific manual pages for a list of supported data format combinations.
The data format fields may be modified only on the /dev/audio device. The audio hardware will often constrain the input and output data formats to be identical. If this is the case, then the data format may not be changed if multiple processes have opened the audio device.
If the parameter changes requested by an AUDIO_SETINFO ioctl cannot all be accommodated, ioctl( ) will return with errno set to EINVAL and no changes will be made to the device state.

Streamio IOCTLS

All of the streamio(7I) ioctl commands may be issued for the /dev/audio device. Because the /dev/audioctl device has its own STREAMS queues, most of these commands neither modify nor report the state of /dev/audio if issued for the /dev/audioctl device. The I_SETSIG ioctl may be issued for /dev/audioctl to enable the notification of audio status changes, as described above.

Audio IOCTLS

The audio device additionally supports the following ioctl commands:
AUDIO_DRAIN
The argument is ignored. This command suspends the calling process until the output STREAMS queue is empty, or until a signal is delivered to the calling process. It may not be issued for the /dev/audioctl device. An implicit AUDIO_DRAIN is performed on the final close( ) of /dev/audio.
AUDIO_GETDEV
The argument is a pointer to an audio_device structure. This command may be issued for either /dev/audio or /dev/audioctl. The returned value in the name field will be a string that will identify the current /dev/audio hardware device, the value in version will be a string indicating the current version of the hardware, and config will be a device-specific string identifying the properties of the audio stream associated with that file descriptor. Refer to the audio devicespecific manual pages to determine the actual strings returned by the device driver.
AUDIO_GETINFO
The argument is a pointer to an audio_info structure. This command may be issued for either /dev/audio or /dev/audioctl. The current state of the /dev/audio device is returned in the structure.
AUDIO_SETINFO
The argument is a pointer to an audio_info structure. This command may be issued for either the /dev/audio or the /dev/audioctl device with some restrictions. This command configures the audio device according to the structure supplied and overwrites the structure with the new state of the device. Note: The play.samples, record.samples, play.error, record.error, and play.eof fields are modified to reflect the state of the device when the AUDIO_SETINFO was issued. This allows programs to automatically modify these fields while retrieving the previous value.
Certain fields in the information structure, such as the pause flags are treated as read-only when /dev/audio is not open with the corresponding access permission. Other fields, such as the gain levels and encoding information, may have a restricted set of acceptable values. Applications that attempt to modify such fields should check the returned values to be sure that the corresponding change took effect. The sample_rate, channels, precision, and encoding fields treated as read-only for /dev/audioctl, so that applications can be guaranteed that the existing audio format will stay in place until they relinquish the audio device. AUDIO_SETINFO will return EINVAL when the desired configuration is not possible, or EBUSY when another process has control of the audio device.
Once set, the following values persist through subsequent open( ) and close( ) calls of the device: play.gain, record.gain, play.balance, record.balance, output_muted, monitor_gain, play.port, and record.port. However, an automatic device driver unload will reset these parameters to their default values on the next load. All other state is reset when the corresponding I/O stream of /dev/audio is closed.
The audio_info structure may be initialized through the use of the AUDIO_INITINFO macro. This macro sets all fields in the structure to values that are ignored by the AUDIO_SETINFO command. For instance, the following code switches the output port from the built-in speaker to the headphone jack without modifying any other audio parameters:
audio_info_tinfo;
AUDIO_INITINFO(&info);
info.play.port = AUDIO_HEADPHONE;
err = ioctl(audio_fd, AUDIO_SETINFO, &info);
This technique eliminates problems associated with using a sequence of AUDIO_GETINFO followed by AUDIO_SETINFO.

ERRORS

An open( ) will fail if:
EBUSY
The requested play or record access is busy and either the O_NDELAY or O_NONBLOCK flag was set in the open( ) request.
EINTR
The requested play or record access is busy and a signal interrupted the open( ) request.
An ioctl( ) will fail if:
EINVAL
The parameter changes requested in the AUDIO_SETINFO ioctl are invalid or are not supported by the device.
EBUSY
The parameter changes requested in the AUDIO_SETINFO ioctl could not be made because another process has the device open and is using a different format.

FILES

The physcial audio device names are system dependent and are rarely used by programmers. The programmer should use the generic device names listed below.
/dev/audio
symbolic link to the system's primary audio device
/dev/audioctl
symbolic link to the control device for /dev/audio
/dev/sound/0
first audio device in the system
/dev/sound/0ctl
audio control device for /dev/sound/0

SEE ALSO

close(2), fcntl(2), ioctl(2), open(2), poll(2), read (2),write(2), audioamd(7D), audiocs(7D), dbri(7D), sbpro(7D), streamio(7I)

BUGS

Due to a feature of the STREAMS implementation, programs that are terminated or exit without closing the audio device may hang for a short period while audio output drains. In general, programs that produce audio output should catch the SIGINT signal and flush the output stream before exiting.
On LX machines running Solaris 2.3, catting a demo audio file to the audio device /dev/audio does not work. Use the audioplay command on LX machines instead of cat.

FUTURE DIRECTIONS

Future workstation audio resources will be managed by an audio foundation library. For the time being, we encourage you to write your programs in a modular fashion, isolating the audio device-specific functions, so that they may be easily ported to such an environment.
The AUDIO_GETDEV ioctl is provided for the future implementation of an audio device capability database. In general, applications may use the play.avail_ports and record.avail_ports fields of the audio_info structure to determine the audio device capabilities.
audioamd(7D)

NAME

audioamd - telephone quality audio device

DESCRIPTION

The audioamd device uses the AM79C30A Digital Subscriber Controller chip to implement the audio device interface. This interface is described fully in the audio(7I) manual page.
Applications that open /dev/audio may use the AUDIO_GETDEV ioctl to determine which audio device is being used. The audioamd driver will return "SUNW,am79c30" in the name field of the audio_device structure. The version field will contain "a" and the config field will be set to "onboard1" .
The AUDIO_SETINFO ioctl controls device configuration parameters. When an application modifies the record.buffer_size field using the AUDIO_SETINFO ioctl, the driver will constrain it to be greater than zero and less than or equal to 8000 bytes or one second of audio data. Applications are warned that setting this field too low or too high may cause system performance problems and should therefore set this field with caution.

Audio Data Formats

The audioamd device supports the audio formats listed in the following table. When the device is open for simultaneous play and record, the input and output data formats must match.
SupportedAudioData Formats
Sample RateEncodingPrecisionChannels
8000 Hz.-law81
8000 HzA-law81
Since audioamd supports only single-channel (monaural) audio, the play.balance and record.balance fields of the audio_info structure are ignored.

Audio Ports

The record.avail_ports and play.avail_ports fields of the audio_info structure report the available input and output ports. The audioamd device supports one input port, selected by setting the record.port field to AUDIO_MICROPHONE . The play.port field may be set to either AUDIO_SPEAKER or AUDIO_HEADPHONE ,to direct audio output to the built-in speaker or headphone jack, respectively. Note that AUDIO_SPEAKER cannot be enabled for systems that do not include a built-in speaker.

Sample Granularity

Since the audioamd device manipulates single samples of audio data, the reported input and output sample counts will be very close to the actual sample count. However, some other audio devices report sample counts that are approximate, due to buffering constraints. Programs should, in general, not rely on absolute accuracy of the sample count fields.

FILES

/dev/audio
/dev/audioctl
/dev/sound
/usr/demo/SOUND

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSPARC: SPARCstation 1 and 2, IPC, IPX, SLC, ELC, LC, and SPARCserver 6xx systems
Desktop SPARCsystems include a built-in speaker for audio output. The audio cable provides connectors for a microphone and external headset. The headset output level is adequate to power most headphones, but may be too low for some external speakers. Powered speakers or an external amplifier may be used. SPARCserver 6xx systems do not have an internal speaker, but support an external microphone and speaker connected through the audio cable.
The Sun Microphone is recommended for normal desktop audio recording. It contains a battery that must be replaced after 210 hours of use. Other microphones may be used, but a pre-amplifier circuit may be required to achieve a sufficient input signal. Other audio sources may be recorded by connecting one channel of the line output to the audio cable microphone input. If the input signal is distorted, external attenuation may be required (audio sources may also be connected from their headphone output with the volume turned down).

SEE ALSO

ioctl(2), attributes(5), audio(7I), streamio(7I)
AMD data sheet for the AM79C30A Digital Subscriber Controller, Publication number 09893.
audiocs(7D)

NAME

audiocs - Crystal Semiconductor 4231 audio Interface

DESCRIPTION

Audiocs is an audio interface that provides line in and line out ports for audio devices. It can be either an integrated device or an add-in option card.

SPARC

SPARCstation 5 systems have the Multimedia Codec integrated onto the CPU board of the machine. In the "onboard" Codec, there are microphone, line in, headphone, and line out ports located on the system back panel. In addition, the headphone and microphone ports do not have the input detection circuitry to determine whether or not there is currently headphones or a microphone plugged in. There is no interface on the SPARCstation 5 for the speakerbox to connect to.
SPARCstation 4 systems have ports for microphone, line in, headphone, and line out, as well as a port for an internal CD-ROM.
For all SPARCstations, the new Sun Microphone II is recommended for normal desktop audio recording. Other audio sources may be recorded by connecting their line output to the line input (audio sources may also be connected from their headphone output if the volume is adjusted properly).

Ultra

Ultra systems have ports for microphone, line in, headphone and line out.

x86

The Multimedia Codec may be found as either an integrated motherboard device, or as an add-in option card. An internal CD-ROM is also a common input option.

APPLICATION PROGRAM

Applications that open /dev/audio may use the AUDIO_GETDEV ioctl to determine which audio device is being used. The audiocs driver will return the string "SUNW,CS4231" in the name field of the audio_device structure. The version field will contain one of the following values, depending upon the platform:

INTERFACE

Platform Type
Version
SPARCstation 4/5
a
Ultra
b
reserved
c
The config field will contain the following value: "onboard1" on a /dev/audio stream associated with the onboard Multimedia Codec.
The AUDIO_SETINFO ioctl controls device configuration parameters. When an application modifies the record.buffer_size field using the AUDIO_SETINFO ioctl, the driver will constrain it to be non-zero and up to a maximum of 8180 bytes.

Audio Data Formats

The Multimedia 4231 Codec audiocs device supports the audio formats listed in the following table. When the device is open for simultaneous play and record, the input and output data formats must match.
Supported Audio Data Formats
Sample Rate     Encoding      Precision  Channels
 8000 Hz     .-law or A-law      8          1
 9600 Hz     .-law or A-law      8          1
 11025 Hz    .-law or A-law      8          1
 16000 Hz    .-law or A-law      8          1
 18900 Hz    .-law or A-law      8          1
 22050 Hz    .-law or A-law      8          1
 32000 Hz    .-law or A-law      8          1
 37800 Hz    .-law or A-law      8          1
 44100 Hz    .-law or A-law      8          1
 48000 Hz    .-law or A-law      8          1
 8000 Hz         linear         16        1 or 2
 9600 Hz         linear         16        1 or 2
 11025 Hz        linear          16       1 or 2
 16000 Hz        linear          16       1 or 2
 18900 Hz        linear          16       1 or 2
 22050 Hz        linear          16       1 or 2
 32000 Hz        linear          16       1 or 2
 37800 Hz        linear          16       1 or 2
 44100 Hz        linear          16       1 or 2
 48000 Hz        linear          16       1 or 2

Audio Ports

The record.avail_ports and play.avail_ports fields of the audio_info structure report the available input and output ports. In most environments, the audiocs device supports three input ports, except the Ultra product family which supports only two. These input ports are selected by setting the record.port field to either AUDIO_MICROPHONE , AUDIO_LINE_IN ,or AUDIO_INTERNAL_CD_IN . (Ultra systems do not support AUDIO_INTERNAL_CD_IN .) If you select the AUDIO_INTERNAL_CD_IN this will select input from the internal CD drive, if present. This will allow you to gather data from the CD without having to hook up a connecting line from the headphone jack to the line input jack. The play.port field may be set to any combination of AUDIO_SPEAKER , AUDIO_HEADPHONE ,and AUDIO_LINE_OUT by OR'ing the desired port names together. (Note: On some systems, the headphone and line out ports internally share the same circuitry; in these cases, it is not possible to enable either output exclusively.)

Sample Granularity

Since the audiocs device manipulates buffers of audio data, at any given time the reported input and output sample counts will vary from the actual sample count by no more than the size of the buffers it is transferring. Programs should, in general, not rely on absolute accuracy of the play.samples and record.samples fields of the audio_info structure.

Audio Status Change Notification

As described in audio(7I), it is possible to request asynchronous notification of changes in the state of an audio device.

ERRORS

audiocs errors are defined in the audio(7I), man pages.

FILES

The physical device names are very system dependent and are rarely used by programmers.

SPARC Only

/devices/iommu@f,e0000000/sbus@f,e0001000/SUNW,CS4231@2,c00000:sound,audio

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSPARCstation 4/5, x86

SEE ALSO

ioctl(2), attributes(5), audio(7I), streamio(7I)
Crystal Semiconductor, Inc., data sheet for the CS4231 16-Bit, 48 kHz, Multimedia Audio Codec Publication number DS111PP2.

NOTES:

The AUDIO_INTERNAL_CD_IN is another new functionality addition. Because of this, audiotool will now have a new button appear in the record popup box that will allow the user of audiotool to switch to the internal CD (if present).
bd(7M)

NAME

bd - SunButtons and SunDials STREAMS module

SYNOPSIS

open("/dev/bd", O_RDWR)

DESCRIPTION

The bd STREAMS module processes the byte streams generated by the SunButtons buttonbox and SunDials dialbox. The buttonbox generates a stream of bytes that encode the identity and state transition of the buttons. The dialbox generates a stream of bytes that encode the identity of the dials and the amount by which they are turned. Both of these streams are merged together when a host has both a buttonbox and a dialbox in use at the same time.
SunButtons reports the button number and up/down status encoded into a one byte message. Byte values from 0xc0 to 0xdf indicate a transition to button down. To obtain the button number, subtract 0xc0 from the byte value. Byte values from 0xe0 to 0xff indicate a transition to button up. To obtain the button number, subtract 0xe0 from the byte value.
Each dial sample in the byte stream consists of three bytes. The first byte identifies which dial was turned and the next two bytes return the delta in signed binary format. When bound to an application using the window system, Virtual User Input Device events are generated. An event from a dial is constrained to lie between 0x80 and 0x87.
A stream with the bd pushed streams module configured in it can emit firm_events as specified by the protocol of a VUID. bd understands the VUIDSFORMAT and VUIDGFORMAT ioctls (see reference below), as defined in /usr/include/sys/bdio.h and $OPENWINHOME/include/xview/win_event.h. All other ioctl() requests are passed downstream.
The bd streams module sets the parameters of the serial port when it is first opened. No termio (7I)ioctl ( ) requests should be performed on a bd STREAMS module, as bd expects the device parameters to remain as it set them.

bd ( 7M ) IOCTLS

VUIDSFORMAT
VUIDGFORMAT           These are standard Virtual User Input Device ioctls.
BDIOBUTLITE
The bd streams module implements this ioctl to enable processes to manipulate the lights on the buttonbox. The BDIOBUTLITE ioctl must be carried by an I_STR ioctl to the bd module. For an explanation of I_STR see streamio(7I). The data for the
BDIOBUTLITE ioctl is an unsigned integer in which each bit represents the lamp on one button. The macro LED_MAP in <sys/bdio.h> maps button numbers to appropriate bits. Source code for the demo program x_buttontest is provided with the buttons and dials package, and may be found in the directory
/usr/demo/BUTTONBOX. Look at x_buttontest.c for an example of how to manipulate the lights on the buttonbox.

FILES

/usr/include/sys/bdio.h
/usr/include/sys/stropts.h
$OPENWINHOME/share/include/xview/win_event.h

SEE ALSO

bdconfig (1M),ioctl(2), x_dialtest(6), x_buttontest(6), streamio(7I), termio (7I)
SunDials Installation and Programmers Guide
SunButtons Installation and Programmers Guide

WARNINGS

The SunDials dial box must be used with a serial port.
be(7D)

NAME

be - BigMAC Fast Ethernet device driver

SYNOPSIS

#include <sys/bmac.h>
#include <sys/be.h>
#include <sys/qec.h>
#include <sys/dlpi.h>

DESCRIPTION

The 10/100 Mbit/s Fast Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware device driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over 10/100 Mbit/s 802.30 controller in the SBus Fast Ethernet card. There is no software limitation on the number of Fast Ethernet cards supported by the driver. The be driver provides basic support for the BigMAC hardware. Functions include chip initialization, frame transmit and receive, multicast and promiscuous support, and error recovery and reporting.
The cloning character-special device /dev/be is used to access the 10/100 Mbit/s device installed within the system.

be and DLPI

The be driver is a "style 2" Data Link Service provider; an explicit DL_ATTACH_REQ message by the user is required to associate the opened Stream with a particular device (ppa). The ppa ID is interpreted as an unsigned long and indicates the corresponding device instance (unit) number. An error (DL_ERROR_ACK )is returned by the driver if the ppa field value does not correspond to a valid device instance number for this system (see prtconf(1M)).
All M_PROTO and M_PCPROTO type messages are interpreted as DLPI primitives.
The device is initialized on first attach and de-initialized (stopped) on last detach.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The max SDU (Service Data Unit) is 1500 (ETHERMTU ).
The min SDU (Service Data Unit) is 0 .
The dlsap address length is 8 . The physical address component is 6 bytes followed immediately by a 2-byte sap component within the DLSAP address.
The MAC type is DL_ETHER .
The sap length value is -2 ,which means the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The service mode is DL_CLDLS .
No optional quality of service (QOS) support is included at present so the QOS fields are 0 .
The provider style is DL_STYLE2 .
The version is DL_VERSION_2 .
The broadcast address value is Ethernet/IEEE broadcast address (0xFFFFFFFF).
When in the DL_ATTACHED state, the user must send a DL_BIND_REQ to associate a particular SAP (Service Access Point) with the Stream. The be driver interprets the sap field within the DL_BIND_REQ as an Ethernet "type"; therefore, valid values for the sap field are in the [0 -0xFFFF] range. Only one Ethernet type can be bound to the Stream at any time.
10/100 Mbit/s algorithm for auto-selection is to be determined.
If the user selects a sap with a value of 0 ,the receiver will be in 802.3 mode. All frames received from the media having a "type" field in the range [0 -1500 ]are assumed to be 802.3 frames and are routed up all open Streams which are bound to sap value 0 . If more than one Stream is in "802.3 mode" then the frame will be duplicated and routed up multiple Streams as DL_UNITDATA_IND messages.
In transmission, the driver checks the sap field of the DL_BIND_REQ if the sap value is 0 , and if the destination type field is in the range [0 -1500 ]. If either is true, the driver computes the length of the message, not including initial M_PROTO mblk (message block), of all subsequent DL_UNITDATA_REQ messages and transmits 802.3 frames that have this value in the MAC frame header length field.
The driver also supports raw M_DATA mode. When the user sends a DLIOCRAW ioctl, the particular Stream is put in raw mode. A complete frame along with a proper ether header is expected as part of the data.
The be driver DLSAP address format consists of the 6-byte physical (Ethernet) address component followed immediately by the 2-byte sap (type) component producing an 8-byte DLSAP address. Applications should not hardcode to this particular implementation-specific DLSAP address format but use information returned by the DL_INFO_ACK primitive to compose and decompose DLSAP addresses. The sap length, full DLSAP length, and sap/physical ordering are included within the DL_INFO_ACK. The physical address length can be computed by subtracting the sap length from the full DLSAP address length or by issuing the DL_PHYS_ADDR_REQ to obtain the current physical address associated with the Stream.
When in the DL_BOUND state, the user may transmit frames on the Fast Ethernet by sending DL_UNITDATA_REQ messages to the be driver. The be driver routes received Fast Ethernet frames as DL_UNITDATA_IND messages up all the open and bound Streams that have sap matching the Fast Ethernet type. Received Fast Ethernet frames are duplicated and routed up multiple open Streams if necessary. The DLSAP address contained within the DL_UNITDATA_REQ and DL_UNITDATA_IND messages consists of both the sap (type) and physical (Fast Ethernet) components.

be Primitives

In addition to the mandatory connectionless DLPI message set the driver additionally supports the following primitives.
The DL_ENABMULTI_REQ and DL_DISABMULTI_REQ primitives enable/disable reception of individual multicast group addresses. A set of multicast addresses may be iteratively created and modified on a per-stream basis with these primitives. These primitives
are accepted by the driver in any state following DL_ATTACHED .
The DL_PROMISCON_REQ and DL_PROMISCOFF_REQ primitives with the DL_PROMISC_PHYS flag set in the dl_level field enables/disables reception of all ("promiscuous mode") frames on the media including frames generated by the local host. When used with the DL_PROMISC_SAP flag set this enables/disables reception of all sap (Fast Ethernet type) values. When used with the DL_PROMISC_MULTI flag set this enables/disables reception of all multicast group addresses. The effect of each is always on a per-stream basis and independent of the other sap and physical level configurations on this Stream or other Streams.
The DL_PHYS_ADDR_REQ primitive return the 6-octet Fast Ethernet address currently associated (attached) to the Stream in the DL_PHYS_ADDR_ACK primitive. This primitive is valid only in states following a successful DL_ATTACH_REQ .
The DL_SET_PHYS_ADDR_REQ primitive changes the 6-octet Fast Ethernet address currently associated (attached) to this Stream. The owner of the process which originally opened this Stream must be superuser or EPERM is returned in the DL_ERROR_ACK .This primitive is destructive in that it affects all other current and future Streams attached to this device. An M_ERROR is sent up all other Streams attached to this device when this primitive on this Stream is successful. Once changed, all Streams subsequently opened and attached to this device will obtain this new physical address. Once changed, the physical address will remain so until this primitive is used to change the physical address again or the system is rebooted, whichever comes first.

FILES

/dev/be
be special character device.

SEE ALSO

prtconf(1M), dlpi(7P), ie(7D), le(7D), qe(7D)
blogic(7D)

NAME

blogic - low-level module for Mylex/BusLogic host bus adapters

SYNOPSIS

blogic@reg

DESCRIPTION

The blogic module provides low-level interface routines between the common disk/tape I/O subsystem and the Mylex/BusLogic bus master SCSI (Small Computer System Interface) controllers. The blogic module can be configured for disk and streaming tape support for one or more host bus adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and determines what types of devices are attached to to the adapter.
To view the BusLogic host adapters supported by the blogic module, see the Hardware Compatibility List Module in the Information Library.

CONFIGURATION

The driver attempts to configure itself in accordance with the information found in the configuration file blogic.conf.

FILES

/kernel/drv/blogic.conf
blogic device driver configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

driver.conf(4), attributes(5), sysbus(4)
bpp(7D)

NAME

bpp - bi-directional parallel port driver

SYNOPSIS

SUNW,bpp@slot, offset:bppn

DESCRIPTION

The bpp driver provides a general-purpose bi-directional interface to parallel devices. It supports a variety of output (printer) and input (scanner) devices, using programmable timing relationships between the various handshake signals.

APPLICATION PROGRAMMING

The bpp driver is an exclusive-use device. If the device has already been opened, subsequent opens fail with EBUSY .

INTERFACE

Default Operation

Each time the bpp device is opened, the default configuration is BPP_ACK_BUSY_HS for read handshake, BPP_ACK_HS for write handshake, 1 microsecond for all setup times and strobe widths, and 60 seconds for both timeouts. This configuration (in the write mode) drives many common personal computer parallel printers with Centronics-type interfaces. The application should use the BPPIOC_SETPARMS ioctl request to configure the bpp for the particular device which is attached, if necessary.

Write Operation

If a failure or error condition occurs during a write(2), the number of bytes successfully written is returned (short write). Note that errno will not be set. The contents of certain status bits will be captured at the time of the error, and can be retrieved by the application program, using the BPPIOC_GETERR ioctl request. Subsequent write(2) calls may fail with the system error ENXIO if the error condition is not rectified. The captured status information will be overwritten each time an attempted transfer or a BPPIOC_TESTIO ioctl request occurs.

Read Operations

If a failure or error condition occurs during a read (2),the number of bytes successfully read is returned (short read). Note that errno will not be set. The contents of certain status bits will be captured at the time of the error, and can be retrieved by the application, using the BPPIOC_GETERR ioctl request. Subsequent read (2)calls may fail with ENXIO if the error condition is not rectified. The captured register information will be overwritten each time an attempted transfer or a BPPIOC_TESTIO ioctl request.
If the read_handshake element of the bpp_transfer_parms structure (see below) is set to BPP_CLEAR_MEM or BPP_SET_MEM ,zeroes or ones, respectively, are written into the user buffer.

Read/Write Operation

When the driver is opened for reading and writing, it is assumed that scanning will take place, as scanners are the only devices supported by this mode. Most scanners require that the SLCT_IN or AFX pin be set to tell the scanner the direction of the transfer. The AFX line is set when the read_handshake element of the bpp_transfer_parms structure is set to BPP_HSCAN_HS ,otherwise the SLCT_IN pin is set. Normally, scanning starts by writing a command to the scanner, at which time the pin is set. When the scan data is read back, the pin is reset.

IOCTLS

The following ioctl requests are supported:
BPPIOC_SETPARMS
Set transfer parameters.
The argument is a pointer to a bpp_transfer_parms structure. See below for a description of the elements of this structure. If a parameter is out of range, EINVAL is returned.
BPPIOC_GETPARMS
Get current transfer parameters.
The argument is a pointer to a bpp_transfer_parms structure. See below for a description of the elements of this structure. If no parameters have been configured since the device was opened, the contents of the structure will be the default conditions of the parameters (see Default Operation above).
BPPIOC_SETOUTPINS
Set output pin values.
The argument is a pointer to a bpp_pins structure. See below for a description of the elements of this structure. If a parameter is out of range, EINVAL is returned.
BPPIOC_GETOUTPINS
Read output pin values.
The argument is a pointer to a bpp_pins structure. See below for a description of the elements of this structure.
BPPIOC_GETERR
Get last error status.
The argument is a pointer to a bpp_error_status structure. See below for a description of the elements of this structure. This structure indicates the status of all the appropriate status bits at the time of the most recent error condition during a read (2)or write(2) call, or the status of the bits at the most recent BPPIOC_TESTIO ioctl request. Note: The bits in the pin_status element indicate whether the associated pin is active, not the actual polarity. The application can check transfer readiness without attempting another transfer using the BPPIOC_TESTIO ioctl. Note: The timeout_occurred and bus_error fields will never be set by the BPPIOC_TESTIO ioctl, only by an actual failed transfer.
BPPIOC_TESTIO
Test transfer readiness.
This command checks to see if a read or write transfer would succeed based on pin status, opened mode, and handshake selected. If a handshake would succeed, 0 is returned. If a transfer would fail, -1 is returned, and errno is set to EIO ,and the error status information is captured. The captured status can be retrieved using the BPPIOC_GETERR ioctl call. Note that the timeout_occurred and bus_error fields will never be set by this ioctl.

Transfer Parameters Structure

This structure is defined in <sys/bpp_io.h>.
struct bpp_transfer_parms {
    enum handshake_t
           read_handshake;       /* parallel port read handshake mode * /
    int   read_setup_time;      /* DSS register - in nanoseconds * /
    int   read_strobe_width;    /* DSW register - in nanoseconds * /
    int   read_timeout;         /*
                                 * wait this many seconds
                                 * before aborting a transfer
                                 * /
    enum handshake_t
           write_handshake;      /* parallel port write handshake mode * /
    int   write_setup_time;     /* DSS register - in nanoseconds * /
    int   write_strobe_width; /* DSW register - in nanoseconds * /
    int   write_timeout;        /*
                                 * wait this many seconds
                                 * before aborting a transfer
                                 * /

};
/* Values for read_handshake and write_handshake fields * /
enum       handshake_t {
    BPP_NO_HS ,                 /* no handshake pins * /
    BPP_ACK_HS ,                /* handshake controlled by ACK line * /
    BPP_BUSY_HS ,               /* handshake controlled by BSY line * /
    BPP_ACK_BUSY_HS ,           /*
                                 * handshake controlled by ACK and BSY lines
                                 * read_handshake only!
                                 * /
    BPP_XSCAN_HS ,              /* xerox scanner mode,
                                 * read_handshake only!
                                 * /
    BPP_HSCAN_HS ,              /*
                                 * HP scanjet scanner mode
                                 * read_handshake only!
                                 * /
    BPP_CLEAR_MEM ,             /* write 0's to memory,
                                 * read_handshake only!
                                 * /
    BPP_SET_MEM ,               /* write 1's to memory,
                                 * read_handshake only!
                                 * /
    /* The following handshakes are RESERVED .Do not use. * /
    BPP_VPRINT_HS ,             /* valid only in read/write mode * /
    BPP_VPLOT_HS                /* valid only in read/write mode * /
};
The read_setup_time field controls the time between dstrb falling edge to bsy rising edge if the read_handshake field is set to BPP_NO_HS or BPP_ACK_HS . It controls the time between dstrb falling edge to ack rising edge if the read_handshake field is set to BPP_ACK_HS or BPP_ACK_BUSY_HS . It controls the time between ack falling edge to dstrb rising edge if the read_handshake field is set to BPP_XSCAN_HS .
The read_strobe_width field controls the time between ack rising edge and ack falling edge if the read_handshake field is set to BPP_NO_HS or BPP_ACK_BUSY_HS . It controls the time between dstrb rising edge to dstrb falling edge if the read_handshake field is set to BPP_XSCAN_HS .
The values allowed for the write_handshake field are duplicates of the definitions for the read_handshake field. Note that some of these handshake definitions are only valid in one mode or the other.
The write_setup_time field controls the time between data valid to dstrb rising edge for all values of the write_handshake field.
The write_strobe_width field controls the time between dstrb rising edge and dstrb falling edge if the write_handshake field is not set to BPP_VPRINT_HS or BPP_VPLOT_HS . It controls the minimum time between dstrb rising edge to dstrb falling edge if the write_handshake field is set to BPP_VPRINT_HS or BPP_VPLOT_HS .

Transfer Pins Structure

This structure is defined in <sys/bpp_io.h>.
struct bpp_pins {
    u_char output_reg_pins;        /* pins in P_OR register * /
    u_char input_reg_pins;         /* pins in P_IR register * /
};
/* Values for output_reg_pins field * /
#define BPP_SLCTIN_PIN 0x01         /* Select in pin * /
#define BPP_AFX_PIN        0x02     /* Auto feed pin * /
#define BPP_INIT_PIN       0x04     /* Initialize pin * /
#define BPP_V1_PIN         0x08     /* reserved pin 1 * /
#define BPP_V2_PIN         0x10     /* reserved pin 2 * /
#define BPP_V3_PIN         0x20     /* reserved pin 3 * /
#define BPP_ERR_PIN
0x01
/* Error pin * /
#define BPP_SLCT_PIN       0x02     /* Select pin * /
#define BPP_PE_PIN         0x04     /* Paper empty pin * /

Error Pins Structure

This structure is defined in the include file <sys/bpp_io.h>.
struct bpp_error_status {
    char    timeout_occurred;      /* 1 if a timeout occurred * /
    char    bus_error;             /* 1 if an SBus bus error * /
    u_char pin_status;             /*
                                    * status of pins which could
                                    * cause an error
                                    * /
};
/* Values for pin_status field * /
#define BPP_ERR_ERR        0x01     /* Error pin active * /
#define BPP_SLCT_ERR       0x02     /* Select pin active * /
#define BPP_PE_ERR         0x04     /* Paper empty pin active * /
#define BPP_SLCTIN_ERR 0x10         /* Select in pin active* /
#define BPP_BUSY_ERR       0x40     /* Busy pin active * /

ERRORS

EBADF
The device is opened for write-only access and a read is attempted, or the device is opened for read-only access and a write is attempted.
EBUSY
The device has been opened and another open is attempted.
An attempt has been made to unload the driver while one of the units is open.
EINVAL
A BPPIOC_SETPARMS ioctl is attempted with an out of range value in the bpp_transfer_parms structure.
A BPPIOC_SETOUTPINS ioctl is attempted with an invalid value in the pins structure.
An ioctl is attempted with an invalid value in the command argument. An invalid command argument is received during modload(1M) or modunload(1M).
EIO
The driver encountered an SBus bus error when attempting an access.
A read or write does not complete properly, due to a peripheral error or a transfer timeout.
A BPPIOC_TESTIO ioctl call is attempted while a condition exists which would prevent a transfer (such as a peripheral error).
ENXIO
The driver has received an open request for a unit for which the attach failed.
The driver has received a read or write request for a unit number greater than the number of units available.
The driver has received a write request for a unit which has an active peripheral error.

FILES

/dev/bppn
bi-directional parallel port devices

SEE ALSO

ioctl(2), read (2),write(2), sbus(4)
bufmod(7M)

NAME

bufmod - STREAMS Buffer Module

SYNOPSIS

ioctl(fd, I_PUSH, "bufmod");

DESCRIPTION

bufmod is a STREAMS module that buffers incoming messages, reducing the number of system calls and the associated overhead required to read and process them. Although bufmod was originally designed to be used in conjunction with STREAMS -basednetworking device drivers, the version described here is general purpose so that it can be used anywhere STREAMS input buffering is required.

Read-side Behavior

bufmod's behavior depends on various parameters and flags that can be set and queried as described below under IOCTLS . bufmod collects incoming M_DATA messages into chunks, passing each chunk upstream when the chunk becomes full or the current read timeout expires. It optionally converts M_PROTO messages to M_DATA and adds them to chunks as well. It also optionally adds to each message a header containing a timestamp, and a cumulative count of messages dropped on the stream read side due to resource exhaustion or flow control. bufmod's default settings allow it to drop messages when flow control sets in or resources are exhausted; disabling headers and explicitly requesting no drops makes bufmod pass all messages through. Finally, bufmod is capable of truncating upstream messages to a fixed, programmable length.
When a message arrives, bufmod processes it in several steps. The following paragraphs discuss each step in turn.
Upon receiving a message from below, if the SB_NO_HEADER flag is not set, bufmod immediately timestamps it and saves the current time value for later insertion in the header described below.
Next, if SB_NO_PROTO_CVT is not set, bufmod converts all leading M_PROTO blocks in the message to M_DATA blocks, altering only the message type field and leaving the contents alone.
It then truncates the message to the current snapshot length, which is set with the SBIOCSSNAP ioctl described below.
Afterwards, if SB_NO_HEADER is not set, bufmod prepends a header to the converted message. This header is defined as follows.
struct sb_hdr {
        u_int   sbh_origlen;
        u_int   sbh_msglen;
        u_int   sbh_totlen;
        u_int   sbh_drops;
        struct  timeval sbh_timestamp;
};
The sbh_origlen field gives the message's original length before truncation in bytes. The sbh_msglen field gives the length in bytes of the message after the truncation has been done. sbh_totlen gives the distance in bytes from the start of the truncated message in the current chunk (described below) to the start of the next message in the chunk; the
value reflects any padding necessary to insure correct data alignment for the host machine and includes the length of the header itself. sbh_drops reports the cumulative number of input messages that this instance of bufmod has dropped due to flow control or resource exhaustion. In the current implementation message dropping due to flow control can occur only if the SB_NO_DROPS flag is not set. (Note: this accounts only for events occurring within bufmod, and does not count messages dropped by downstream or by upstream modules.) The sbh_timestamp field contains the message arrival time expressed as a struct timeval.
After preparing a message, bufmod attempts to add it to the end of the current chunk, using the chunk size and timeout values to govern the addition. The chunk size and timeout values are set and inspected using the ioctl( ) calls described below. If adding the new message would make the current chunk grow larger than the chunk size, bufmod closes off the current chunk, passing it up to the next module in line, and starts a new chunk. If adding the message would still make the new chunk overflow, the module passes it upward in an over-size chunk of its own. Otherwise, the module concatenates the message to the end of the current chunk.
To ensure that messages do not languish forever in an accumulating chunk, bufmod maintains a read timeout. Whenever this timeout expires, the module closes off the current chunk and passes it upward. The module restarts the timeout period when it receives a read side data message and a timeout is not currently active. These two rules insure that bufmod minimizes the number of chunks it produces during periods of intense message activity and that it periodically disposes of all messages during slack intervals, but avoids any timeout overhead when there is no activity.
bufmod handles other message types as follows. Upon receiving an M_FLUSH message specifying that the read queue be flushed, the module clears the currently accumulating chunk and passes the message on to the module or driver above. (Note: bufmod uses zero length M_CTL messages for internal synchronization and does not pass them through.) bufmod passes all other messages through unaltered to its upper neighbor, maintaining message order for non high priority messages by passing up any accumulated chunk first.
If the SB_DEFER_CHUNK flag is set, buffering does not begin until the second message is received within the timeout window.
If the SB_SEND_ON_WRITE flag is set, bufmod passes up the read side any buffered data when a message is received on the write side. SB_SEND_ON_WRITE and SB_DEFER_CHUNK are often used together.

Write-side Behavior

bufmod intercepts M_IOCTL messages for the ioctls described below. The module passes all other messages through unaltered to its lower neighbor. If SB_SEND_ON_WRITE is set, message arrival on the writer side suffices to close and transmit the current read side chunk.

IOCTLS

bufmod responds to the following ioctls.
SBIOCSTIME
Set the read timeout value to the value referred to by the struct timeval pointer given as argument. Setting the timeout value to zero has the
side-effect of forcing the chunk size to zero as well, so that the module will pass all incoming messages upward immediately upon arrival. Negative values are rejected with an EINVAL error.
SBIOCGTIME
Return the read timeout in the struct timeval pointed to by the argument. If the timeout has been cleared with the SBIOCCTIME ioctl, return with an ERANGE error.
SBIOCCTIME
Clear the read timeout, effectively setting its value to infinity. This results in no timeouts being active and the chunk being delivered when it is full.
SBIOCSCHUNK
Set the chunk size to the value referred to by the u_int pointer given as argument. See NOTES for description of effect on stream head high water mark.
SBIOCGCHUNK
Return the chunk size in the u_int pointed to by the argument.
SBIOCSSNAP
Set the current snapshot length to the value given in the u_int pointed to by the ioctl's final argument. bufmod interprets a snapshot length value of zero as meaning infinity, so it will not alter the message. See NOTES for description of effect on stream head high water mark.
SBIOCGSNAP
Returns the current snapshot length in the u_int pointed to by the ioctl's final argument.
SBIOCSFLAGS
Set the current flags to the value given in the u_int pointed to by the ioctl's final argument. Possible values are a combination of the following.
SB_SEND_ON_WRITE Transmit the read side chunk on arrival of a
message on the write side.
SB_NO_HEADER
Do not add headers to read side messages.
SB_NO_DROPS
Do not drop messages due to flow control
upstream.
SB_NO_PROTO_CVT Do not convert M_PROTO messages into
M_DATA .
SB_DEFER_CHUNK
Begin buffering on arrival of the second read
side message in a timeout interval.
SBIOCGFLAGS
Returns the current flags in the u_int pointed to by the ioctl's final argument.

SEE ALSO

dlpi(7P), ie(7D), le(7D), pfmod(7M)

NOTES

Older versions of bufmod did not support the behavioral flexibility controlled by the SBIOCSFLAGS ioctl. Applications that wish to take advantage of this flexibility can guard themselves against old versions of the module by invoking the SBIOCGFLAGS ioctl and checking for an EINVAL error return.
When buffering is enabled by issuing an SBIOCSCHUNK ioctl to set the chunk size to a non zero value, bufmod sends a SETOPTS message to adjust the stream head high and low water marks to accommodate the chunked messages.
When buffering is disabled by setting the chunk size to zero, message truncation can have a significant influence on data traffic at the stream head and therefore the stream head high and low water marks are adjusted to new values appropriate for the smaller truncated message sizes.

BUGS

bufmod does not defend itself against allocation failures, so that it is possible, although very unlikely, for the stream head to use inappropriate high and low water marks after the chunk size or snapshot length have changed.
bwtwo(7D)

NAME

bwtwo - black and white memory frame buffer

SYNOPSIS

/dev/fbs/bwtwo

DESCRIPTION

The bwtwo interface provides access to monochrome memory frame buffers. It supports the ioctls described in fbio(7I).
Reading or writing to the frame buffer is not allowed -- you must use the mmap(2) system call to map the board into your address space.

FILES

/dev/fbs/bwtwo[0-9]
device files

SEE ALSO

mmap(2), cgfour(7D), fbio(7I)

BUGS

Use of vertical-retrace interrupts is not supported.
cdio(7I)

NAME

cdio - CD-ROM control operations

SYNOPSIS

#include <sys/cdio.h>

DESCRIPTION

The set of ioctl(2) commands described below are used to perform audio and CD-ROM specific operations. Basic to these cdio ioctl requests are the definitions in <sys/cdio.h>.
Several CD-ROM specific commands can report addresses either in LBA (Logical Block Address) format or in MSF (Minute, Second, Frame) format. The READ HEADER ,READ SUBCHANNEL ,and READ TABLE OF CONTENTS commands have this feature.
LBA format represents the logical block address for the CD-ROM absolute address field or for the offset from the beginning of the current track expressed as a number of logical blocks in a CD-ROM track relative address field. MSF format represents the physical address written on CD-ROM discs, expressed as a sector count relative to either the beginning of the medium or the beginning of the current track.

IOCTLS

The following I/O controls do not have any additional data passed into or received from them.
CDROMSTART
This ioctl( ) spins up the disc and seeks to the last address
requested.
CDROMSTOP
This ioctl( ) spins down the disc.
CDROMPAUSE
This ioctl( ) pauses the current audio play operation.
CDROMRESUME
This ioctl( ) resumes the paused audio play operation.
CDROMEJECT
This ioctl( ) ejects the caddy with the disc.
The following I/O controls require a pointer to the structure for that ioctl( ), with data being passed into the ioctl( ).
CDROMPLAYMSF
This ioctl( ) command requests the drive to output the audio signals at the specified starting address and continue the audio play until the specified ending address is detected. The address is in MSF format. The third argument of this ioctl( ) call is a pointer to the type struct cdrom_msf.
/*
* definition of play audio msf structure
* /
struct cdrom_msf {
     unsigned char   cdmsf_min0;       /* starting minute* /
     unsigned char   cdmsf_sec0;       /* starting second* /
     unsigned char   cdmsf_frame0;     /* startingframe* /
     unsigned char   cdmsf_min1;       /* ending minute * /
     unsigned char   cdmsf_sec1;       /* ending second * /
     unsigned char   cdmsf_frame1;     /* ending frame * /
};
The CDROMREADTOCENTRY ioctl request may be used to obtain the start time for a track. An approximation of the finish time can be obtained by using the CDROMREADTOCENTRY ioctl request to retrieve the start time of the track following the current track.
The leadout track is the next consecutive track after the last audio track. Hence, the start time of the leadout track may be used as the effective finish time of the last audio track.
CDROMPLAYTRKIND
This ioctl( ) command is similar to CDROMPLAYMSF. The starting and ending address is in track/index format. The third argument of the ioctl( ) call is a pointer to the type struct cdrom_ti.
/*
                      * definition of play audio track/index structure
                      * /
                      struct cdrom_ti {
                           unsigned char   cdti_trk0;        /* starting track* /
                           unsigned char   cdti_ind0;        /* starting index* /
                           unsigned char   cdti_trk1;        /* ending track * /
                           unsigned char   cdti_ind1;        /* ending index * /
                      };
CDROMVOLCTRL
This ioctl( ) command controls the audio output level. The SCSI command allows the control of up to four channels. The current implementation of the supported CD-ROM drive only uses channel 0 and channel 1. The valid values of volume control are between 0x00 and 0xFF, with a value of 0xFF indicating maximum volume. The third argument of the ioctl( ) call is a pointer to struct
cdrom_volctrl which contains the output volume values.
/*
* definition of audio volume control structure
* /
struct cdrom_volctrl {
     unsigned char   channel0;
     unsigned char   channel1;
     unsigned char   channel2;
     unsigned char   channel3;
};
The following I/O controls take a pointer that will have data returned to the user program from the CD-ROM driver.
CDROMREADTOCHDR
This ioctl( ) command returns the header of the table of contents (TOC). The header consists of the starting tracking number and the ending track number of the disc. These two numbers are returned through a pointer of struct cdrom_tochdr. While the disc can start
at any number, all tracks between the first and last tracks are in contiguous ascending order.
/*
                      * definition of read toc header structure
                      * /
                      struct cdrom_tochdr {
                           unsigned char   cdth_trk0;        /* starting track* /
                           unsigned char   cdth_trk1;        /* ending track* /
                      };
CDROMREADTOCENTRY
This ioctl( ) command returns the information of a specified track. The third argument of the function call is a pointer to the type struct cdrom_tocentry. The caller needs to supply the track
number and the address format. This command will return a 4-bit adr field, a 4-bit ctrl field, the starting address in MSF format or LBA format, and the data mode if the track is a data track. The ctrl field specifies whether the track is data or audio.
/*
* definition of read toc entry structure
* /
struct cdrom_tocentry {
     unsigned char cdte_track;
     unsigned char cdte_adr :4;
     unsigned char cdte_ctrl :4;
     unsigned char cdte_format;
     union {
                struct {
                           unsigned char minute;
                           unsigned char second;
                           unsigned char frame;
                } msf;
                int        lba;
     } cdte_addr;
     unsigned char cdte_datamode;
};
To get the information from the leadout track, the following value is appropriate for the cdte_track field:
CDROM_LEADOUT
Leadout track
To get the information from the data track, the following value is appropriate for the cdte_ctrl field:
CDROM_DATA_TRACK
Data track
The following values are appropriate for the cdte_adr field:
CDROM_LBA
LBA format
CDROM_MSF
MSF format
CDROMSUBCHNL
This ioctl( ) command reads the Q sub-channel data of the current block. The subchannel data includes track number, index number, absolute CD-ROM address, track relative CD-ROM address, control data and audio status. All information is returned through a pointer to struct cdrom_subchnl. The caller needs to supply the address format for the returned address.
struct cdrom_subchnl {
     unsigned char         cdsc_format;
     unsigned char         cdsc_audiostatus;
     unsigned char         cdsc_adr: 4;
     unsigned char         cdsc_ctrl: 4;
     unsigned char         cdsc_trk;
     unsigned char         cdsc_ind;
     union {
                struct {
                           unsigned char minute;
                           unsigned char second;
                           unsigned char frame;
                } msf;
                int        lba;
     } cdsc_absaddr;
     union {
                struct {
                           unsigned char minute;
                           unsigned char second;
                           unsigned char frame;
                } msf;
                int        lba;
     } cdsc_reladdr;
};
The following values are valid for the audio status field returned from READ SUBCHANNEL command:
CDROM_AUDIO_INVALID
Audio status not supported.
CDROM_AUDIO_PLAY
Audio play operation in pro-
gress.
CDROM_AUDIO_PAUSED
Audio play operation paused.
CDROM_AUDIO_COMPLETED
Audio play successfully com-
pleted.
CDROM_AUDIO_ERROR
Audio play stopped due to
error.
CDROM_AUDIO_NO_STATUS
No current audio status to
return.
CDROMREADOFFSET
                      This ioctl( ) command returns the absolute CD-ROM address of the
                      first track in the last session of a Multi-Session CD-ROM . The third
                      argument of the ioctl( ) call is a pointer to an int.
CDROMCDDA
SPARC: This ioctl( ) command returns the CD-DA data or the subcode data. The third argument of the ioctl( ) call is a pointer to the type struct cdrom_cdda. In addition to allocating memory and supplying its address, the caller needs to supply the starting
address of the data, the transfer length, and the subcode options. The caller also needs to issue the CDROMREADTOCENTRY ioctl( ) to find out which tracks contain CD-DA data before issuing this ioctl( ).
/*
* Definition of CD-DA structure
* /
struct cdrom_cdda {
     unsigned int          cdda_addr;
     unsigned int          cdda_length;
     caddr_t               cdda_data;
     unsigned char         cdda_subcode;
};
To get the subcode information related to CD-DA data, the following values are appropriate for the cdda_subcode field:
CDROM_DA_NO_SUBCODE
CD-DA data with no subcode.
CDROM_DA_SUBQ
CD-DA data with sub Q code.
CDROM_DA_ALL_SUBCODE
CD-DA data with all subcode.
CDROM_DA_SUBCODE_ONLY
All subcode only.
To allocate the memory related to CD-DA and/or subcode data, the following values are appropriate for each data block
transferred:
CD-DA data with no subcode
2352 bytes
CD-DA data with sub Q code
2368 bytes
CD-DA data with all subcode
2448 bytes
All subcode only
96 bytes
CDROMCDXA
SPARC: This ioctl( ) command returns the CD-ROM XA (CD-ROM Extended Architecture) data according to CD-ROM XA format. The third argument of the ioctl( ) call is a pointer to the type struct cdrom_cdxa. In addition to allocating memory and supplying its address, the caller needs to supply the starting address of the data, the transfer length, and the format. The caller also needs to issue the CDROMREADTOCENTRY ioctl( ) to find out which tracks contain CD-ROM XA data before issuing this ioctl( ).
/*
* Definition of CD-ROM XA structure
* /
struct cdrom_cdxa {
     unsigned int          cdxa_addr;
     unsigned int          cdxa_length;
     caddr_t               cdxa_data;
     unsigned char         cdxa_format;
};
To get the proper CD-ROM XA data, the following values are appropriate for the cdxa_format field:
CDROM_XA_DATA
CD-ROM XA data only
CDROM_XA_SECTOR_DATA
CD-ROM XA all sector data
CDROM_XA_DATA_W_ERROR
CD-ROM XA data with error
flags data
To allocate the memory related to CD-ROM XA format, the following values are appropriate for each data block transferred:
CD-ROM XA data only
2048 bytes
CD-ROM XA all sector data
2352 bytes
CD-ROM XA data with error flags data
2646 bytes
CDROMSUBCODE
SPARC: This ioctl( ) command returns raw subcode data (subcodes P ~ W are described in the "Red Book," see SEE ALSO) to the initiator while the target is playing audio. The third argument of the ioctl( ) call is a pointer to the type struct cdrom_subcode. The caller needs to supply the transfer length and allocate memory for subcode data. The memory allocated should be a multiple of 96
bytes depending on the transfer length.
/*
* Definition of subcode structure
* /
struct cdrom_subcode {
     unsigned int          cdsc_length;
     caddr_t               cdsc_addr;
};
The next group of I/O controls get and set various CD-ROM drive parameters.
CDROMGBLKMODE SPARC: This ioctl( ) command returns the current block size used
by the CD-ROM drive. The third argument of the ioctl( ) call is a pointer to an integer.
CDROMSBLKMODE
SPARC: This ioctl( ) command requests the CD-ROM drive to change from the current block size to the requested block size. The third argument of the ioctl( ) call is an integer which contains the requested block size.
This ioctl( ) command operates in exclusive-use mode only. The caller must ensure that no other processes can operate on the same CD-ROM device before issuing this ioctl( ). read (2)behavior subsequent to this ioctl( ) remains the same: the caller is still constrained to read the raw device on block boundaries and in block multiples.
To set the proper block size, the following values are appropriate:
CDROM_BLK_512
512 bytes
CDROM_BLK_1024
1024 bytes
CDROM_BLK_2048
2048 bytes
CDROM_BLK_2056
2056 bytes
CDROM_BLK_2336
2336 bytes
CDROM_BLK_2340
2340 bytes
CDROM_BLK_2352
2352 bytes
CDROM_BLK_2368
2368 bytes
CDROM_BLK_2448
2448 bytes
CDROM_BLK_2646
2646 bytes
CDROM_BLK_2647
2647 bytes
CDROMGDRVSPEED SPARC: This ioctl( ) command returns the current CD-ROM drive
speed. The third argument of the ioctl( ) call is a pointer to an integer.
CDROMSDRVSPEED SPARC: This ioctl( ) command requests the CD-ROM drive to
change the current drive speed to the requested drive speed. This speed setting is only applicable when reading data areas. The
third argument of the ioctl( ) is an integer which contains the requested drive speed.
To set the CD-ROM drive to the proper speed, the following values are appropriate:
CDROM_NORMAL_SPEED
150k/second
CDROM_DOUBLE_SPEED
300k/second
CDROM_QUAD_SPEED
600k/second
CDROM_MAXIMUM_SPEED
300k/second (2x drive)
600k/second (4x drive)
Note that these numbers are only accurate when reading 2048 byte blocks. The CD-ROM drive will automatically switch to normal speed when playing audio tracks and will switch back to the speed setting when accessing data.

SEE ALSO

ioctl(2), read (2)
N. V. Phillips and Sony Corporation, System Description Compact Disc Digital Audio, ("Red Book").
N. V. Phillips and Sony Corporation, System Description of Compact Disc Read Only Memory, ("Yellow Book").
N. V. Phillips, Microsoft, and Sony Corporation, System Description CD-ROM XA, 1991.
Volume and File Structure of CD-ROM for Information Interchange, ISO 9660:1988(E).
SCSI-2 Standard, document X3T9.2/86-109

NOTES

The CDROMCDDA ,CDROMCDXA ,CDROMSUBCODE ,CDROMGDRVSPEED , CDROMSDRVSPEED and some of the block sizes in CDROMSBLKMODE are designed for new Sun-supported CD-ROM drives and might not work on some of the older CD-ROM drives.
The interface to this device is preliminary and subject to change in future releases. You are encouraged to write your programs in a modular fashion so that you can easily incorporate future changes.
cgeight(7D)

NAME

cgeight - 24-bit color memory frame buffer

SYNOPSIS

/dev/fbs/cgeightn

DESCRIPTION

The cgeight is a 24-bit color memory frame buffer with a monochrome overlay plane and an overlay enable plane implemented optionally on the Sun-4/110, Sun-4/150, Sun-4/260 and Sun-4/280 system models. It provides the standard frame buffer interface as defined in fbio(7I).
In addition to the ioctls described under fbio(7I), the cgeight interface responds to two cgeight-specific colormap ioctls, FBIOPUTCMAP and FBIOGETCMAP. FBIOPUTCMAP returns no information other than success/failure using the ioctl return value. FBIOGETCMAP returns its information in the arrays pointed to by the red, green, and blue members of its fbcmap structure argument; fbcmap is defined in <sys/fbio.h> as:
struct fbcmap {
        int             index;          /* first element (0 origin) * /
        int             count;          /* number of elements * /
        unsigned char * red;            /* red color map elements * /
        unsigned char * green;          /* green color map elements * /
        unsigned char * blue;           /* blue color map elements * /
};
The driver uses color board vertical-retrace interrupts to load the colormap.
The systems have an overlay plane colormap, which is accessed by encoding the plane group into the index value with the PIX_GROUP macro (see <sys/pr_planegroups.h>).
When using the mmap(2) system call to map in the cgeight frame buffer. The device looks like:
DACBASE :0x200000       -> Brooktree Ramdac             16 bytes
        0x202000       -> P4 Register                   4 bytes
OVLBASE :0x210000       -> Overlay Plane                1152x900x1
        0x230000       -> Overlay Enable Planea        1152x900x1
        0x250000       -> 24-bit Frame Buffera         1152x900x32

FILES

/dev/fbs/cgeight0
<sys/fbio.h>
<sys/pr_planegroups.h>

SEE ALSO

mmap(2), fbio(7I)
cgfour(7D)

NAME

cgfour - P4-bus 8-bit color memory frame buffer

SYNOPSIS

/dev/fbs/cgfourn

DESCRIPTION

The cgfour is a color memory frame buffer with a monochrome overlay plane and an overlay enable plane. It provides the standard frame buffer interface as defined in fbio(7I).
In addition to the ioctls described under fbio(7I), the cgfour interface responds to two cgfour-specific colormap ioctls, FBIOPUTCMAP and FBIOGETCMAP. FBIOPUTCMAP returns no information other than success/failure using the ioctl return value. FBIOGETCMAP returns its information in the arrays pointed to by the red, green, and blue members of its fbcmap structure argument; fbcmap is defined in <sys/fbio.h> as:
struct fbcmap {
        int             index;          /* first element (0 origin) * /
        int             count;          /* number of elements * /
        unsigned char * red;            /* red color map elements * /
        unsigned char * green;          /* green color map elements * /
        unsigned char * blue;           /* blue color map elements * /
};
The driver uses color board vertical-retrace interrupts to load the colormap.
The cgfour has an overlay plane colormap, which is accessed by encoding the plane group into the index value with the PIX_GROUP macro (see <sys/pr_planegroups.h>).

FILES

/dev/fbs/cgfour0

SEE ALSO

mmap(2), fbio(7I)
cgfourteen(7D)

NAME

cgfourteen - 24-bit color graphics device

SYNOPSIS

/dev/fbs/cgfourteenn

DESCRIPTION

The cgfourteen device driver controls the video SIMM (VSIMM) component of the video and graphics subsystem of the Desktop SPARCsystems with SX graphics option. The VSIMM provides 24-bit truecolor visuals in a variety of screen resolutions and pixel depths.
The driver supports multi-threaded applications and has an interface accessible through mmap(2). The user must have an effective user ID of 0 to be able to write to the control space of the cgfourteen device.
There are eight distinct physical spaces the user may map, in addition to the control space. The mappings are set up by giving the desired offset to the mmap(2) call.
The cgfourteen device supports the standard frame buffer interface as defined in fbio(7I).
The cgfourteen device can serve as a system console device.
See /usr/include/sys/cg14io.h for other device-specific information.

FILES

/kernel/drv/cgfourteen
cgfourteen device driver
/dev/fbs/cgfourteen[0-9]
Logical device name.
/usr/include/sys/cg14io.h
Header file that contains device specific information
/usr/include/sys/cg14reg.h
Header file that contains device specific information

SEE ALSO

mmap(2), fbio(7I)
cgsix(7D)

NAME

cgsix - accelerated 8-bit color frame buffer

SYNOPSIS

/dev/fbs/cgsixn

DESCRIPTION

cgsix is a low-end graphics accelerator designed to enhance vector and polygon drawing performance. It has an 8-bit color frame buffer and provides the standard frame buffer interface as defined in fbio(7I).
In addition, cgsix supports the following cgsix-specific IOCTL ,defined in <sys/fbio.h>.
FBIOGXINFO
Returns cgsix-specific information about the hardware. See the definition of cg6_info in <sys/fbio.h> for more information.
cgsix has registers and memory that may be mapped with mmap(2), using the offsets defined in <sys/cg6reg.h>.

FILES

/dev/fbs/cgsix0

SEE ALSO

mmap(2), fbio(7I)
cgthree(7D)

NAME

cgthree - 8-bit color memory frame buffer

SYNOPSIS

/dev/fbs/cgthreen

DESCRIPTION

cgthree is a color memory frame buffer. It provides the standard frame buffer interface as defined in fbio(7I).

FILES

/dev/fbs/cgthree[0-9]

SEE ALSO

mmap(2), fbio(7I)
cgtwo(7D)

NAME

cgtwo - color graphics interface

SYNOPSIS

/dev/cgtwon

DESCRIPTION

The cgtwo interface provides access to the color graphics controller board, which is normally supplied with a 19'' 66 Hz non-interlaced color monitor. It provides the standard frame buffer interface as defined in fbio(7I).
The hardware consumes 4 megabytes of VME bus address space. The board starts at standard address 0x400000. The board must be configured for interrupt level 4.

FILES

/dev/cgtwo[0-9]

SEE ALSO

mmap(2), fbio(7I)
cmdk(7D)

NAME

cmdk - common disk driver

SYNOPSIS

cmdk@target, lun : [ partition | slice ]

DESCRIPTION

The cmdk device driver is a common interface to various disk devices. The driver supports magnetic fixed disks, magnetic removable disks, and both 512-byte and 2K-byte CD-ROM drives.
The block-files access the disk using the system's normal buffering mechanism and are read and written without regard to physical disk records. There is also a "raw" interface that provides for direct transmission between the disk and the user's read or write buffer. A single read or write call usually results in one I/O operation; raw I/O is therefore considerably more efficient when many bytes are transmitted. The names of the block files are found in /dev/dsk; the names of the raw files are found in /dev/rdsk.
I/O requests to the magnetic disk must have an offset and transfer length that is a multiple of 512 bytes or the driver returns an EINVAL error. However, I/O requests to the 2K-byte CD-ROM drive must be a multiple of 2K bytes. Otherwise, the driver returns an EINVAL error, too.
Slice 0 is normally used for the root file system on a disk, slice 1 as a paging area (for example, swap), and slice 2 for backing up the entire fdisk partition for Solaris software. Other slices may be used for usr file systems or system reserved area.
Fdisk partition 0 is to access the entire disk and is generally used by the fdisk(1M) program.

FILES

/dev/dsk/cntndn[s|p]n
block device (SCSI)
/dev/dsk/cndn[s|p]n
block device (IDE )
/dev/rdsk/cntndn[s|p]n raw device (SCSI)
/dev/rdsk/cndn[s|p]n
raw device (IDE )
where:
cn
controller n
tn
target id n (0-6)
dn
lun n (0-7)
sn
UNIX system slice n (0-15)
pn
fdisk partition (0)

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

fdisk(1M), mount (1M),lseek(2), read (2),write(2), readdir(3C), scsi(4), vfstab(4), attributes(5), dkio(7I)
connld(7M)

NAME

connld - line discipline for unique stream connections

SYNOPSIS

/dev/connld

DESCRIPTION

connld is a STREAMS -basedmodule that provides unique connections between server and client processes. It can only be pushed (see streamio(7I)) onto one end of a STREAMS -basedpipe that may subsequently be attached to a name in the file system name space with fattach(3C). After the pipe end is attached, a new pipe is created internally when an originating process attempts to open(2) or creat(2) the file system name. A file descriptor for one end of the new pipe is packaged into a message identical to that for the ioctl I_SENDFD (see streamio(7I)) and is transmitted along the stream to the server process on the other end. The originating process is blocked until the server responds.
The server responds to the I_SENDFD request by accepting the file descriptor through the I_RECVFD ioctl message. When this happens, the file descriptor associated with the other end of the new pipe is transmitted to the originating process as the file descriptor returned from open(2) or creat(2).
If the server does not respond to the I_SENDFD request, the stream that the connld module is pushed on becomes uni-directional because the server will not be able to retrieve any data off the stream until the I_RECVFD request is issued. If the server process exits before issuing the I_RECVFD request, the open(2) or the creat(2) invocation will fail and return -1 to the originating process.
When the connld module is pushed onto a pipe, it ignores messages going back and forth through the pipe.

ERRORS

On success, an open of connld returns 0. On failure, errno is set to the following values:
EINVAL
A stream onto which connld is being pushed is not a pipe or the pipe does not have a write queue pointer pointing to a stream head read queue.
EINVAL
The other end of the pipe onto which connld is being pushed is linked under a multiplexor.
EPIPE
connld is being pushed onto a pipe end whose other end is no longer there.
ENOMEM
An internal pipe could not be created.
ENXIO
An M_HANGUP message is at the stream head of the pipe onto which connld is being pushed.
EAGAIN
Internal data structures could not be allocated.
ENFILE
A file table entry could not be allocated.

SEE ALSO

creat(2), open(2), fattach(3C), streamio(7I)
STREAMS Programming Guide
console(7D)

NAME

console - STREAMS-based console interface

SYNOPSIS

/dev/console

DESCRIPTION

The file /dev/console refers to the system console device.

SPARC

The identity of this device depends on the EEPROM or NVRAM settings in effect at the most recent system reboot; by default, it is the ``workstation console'' device consisting of the workstation keyboard and frame buffer acting in concert to emulate an ASCII terminal (see wscons(7D)).

x86

By default the device is the ``workstation console'' device consisting of the workstation keyboard and display (see display(7D) and keyboard(7D)) acting in concert to emulate an ASCII terminal (see wscons(7D)).
In either architecture, regardless of the system configuration, the console device provides asynchronous serial driver semantics so that, in conjunction with the STREAMS line discipline module ldterm(7M), it supports the termio (7I)terminal interface.

SEE ALSO

termios(3), ldterm(7M), termio (7I),wscons(7D)

x86 Only

display(7D), keyboard(7D)

NOTES

In contrast to pre-SunOS 5.0 releases, it is no longer possible to redirect I/O intended for /dev/console to some other device. Instead, redirection now applies to the workstation console device using a revised programming interface (see wscons(7D)). Since the system console is normally configured to be the work station console, the overall effect is largely unchanged from previous releases.
See wscons(7D) for detailed descriptions of control sequence syntax, ANSI control functions, control character functions and escape sequence functions.
corvette(7D)

NAME

corvette - low-level module for IBM Micro Channel SCSI-2 Fast/Wide Adapter/A

DESCRIPTION

The corvette module provides low-level interface routines between the common disk/tape I/O subsystem and the IBM Micro Channel SCSI-2 (Small Computer System Interface) Fast/Wide Adapter/A controllers. The corvette module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and what types of devices are attached to it.

CONFIGURATION

Board Configuration and Auto

The driver attempts to initialize itself in accordance with the information found in the configuration file, /kernel/drv/corvette.conf. Each controller supports two logically independent SCSI busses, an internal bus and an external bus. Each system may support upto 8 controllers depending on the number of available mother-board slots.

Configuration

FILES

/kernel/drv/corvette.conf
configuration file for corvette.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
cpr(7)

NAME

cpr - suspend and resume module

SYNOPSIS

/kernel/misc/cpr

DESCRIPTION

The cpr module is a loadable module used to suspend and resume the entire system. You may wish to suspend a system to save power or to power off temporarily for transport. The cpr module should not be used in place of a normal shutdown when performing any hardware reconfiguration or replacement. In order for the resume operation to succeed, it is important that the hardware configuration remain the same. When the system is suspended, the entire system state is preserved in non-volatile storage until a resume operation is conducted.
The POWER key and the SHIFT+POWER keys on a type 5 keyboard access this module. Two utilities that may be installed on your system that will access this module are uadmin(1M) and uadmin(2).
The module performs the following actions when suspending the system. The signal SIGFREEZE is first sent to all user threads and then the threads are stopped. The system is brought down to a uni-processor mode for multi-processor systems. Dirty user pages are then swapped out to their backing storage device and all file systems are synchronized. All devices are made quiescent and system interrupts are disabled. To complete the system suspend, the kernel memory pages and remaining user pages are written to the root file system in a compressed form.
When the system is powered on again, essentially the reverse of the suspend procedure occurs. The kernel image is restored from the root file system by the bootstrapper /cprboot, interrupts and devices are restored to their previous state. Finally the user threads are rescheduled and SIGTHAW is broadcast to notify any interested processes of system resumption. Additional processors, if available, are restored and brought online. The system is now back to exactly the state prior to suspension.
In some cases the cpr module may be unable to perform the suspend operation. If a system contains additional devices outside the standard shipped configuration, it is possible that these additional devices may not support cpr. In this case, the suspend will fail and an error message will be displayed to that effect. These devices must be removed or their device drivers unloaded for the suspend operation to succeed. Contact the device manufacturer to obtain a new version of device driver that supports cpr. A suspend may also fail when devices or processes are performing critical or time-sensitive operations (such as realtime operations). The system will remain in its current running state. Messages reporting the failure will be displayed on the console and status returned to the caller. Once the system is successfully suspended the resume operation will always succeed, barring external influences such as a hardware reconfiguration.
Some network based applications may fail across a suspend and resume cycle. This largely depends on the underlying network protocol and the applications involved. In general, applications that retry and automatically reestablish connections will continue to operate transparently on a resume operation; those applications that do not will likely fail.
The speed of suspend and resume operations can range from 15 seconds to several minutes, depending on the system speed, memory size, and load. The typical time is approximately one minute.

FILES

/cprboot
special bootstrapper for cpr
/.CPR
system state file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
AvailabilitySUNWcpr

SEE ALSO

uadmin(1M), uadmin(2), attributes(5)

NOTES

For suspend/resume to work on multi-processor platforms, it must be able to control all CPUs. It is recommended that no MP tests (such as sundiag CPU tests) are running when suspend is initiated, because the suspend may be rejected if it cannot shut off all CPUs.
Certain device operations such as tape and floppy disk activities are not resumable due to the nature of removable media. These activities are detected at suspend time, and must be stopped before the suspend operation will complete successfully.

BUGS

The signals SIGFREEZE and SIGTHAW are not properly implemented for the Solaris 2.4 release. They will be available in a later release. This should only be a concern for specially customized applications that need to perform additional tasks at suspend or resume time. No such applications exists at the present time.
In extremely rare occasions, the system may fail during the early stages of a resume operation. In this small window it is theoretically possible to be stuck in a loop that the system does not resume and it does not boot normally. If you are in such a loop, get to the prom ok prompt using the L1+A keys and enter the following command:
<ok> set-default boot-file
This command resets the system and with the next power-on the system will boot normally.
csa(7D)

NAME

csa - low-level module for Compaq SMART SCSI Array Controller

DESCRIPTION

The csa module provides low-level interface routines between the common disk I/O subsystem and the Compaq SMART SCSI (Small Computer System Interface) Array controllers. The csa module can be configured for disk support for one or more host adapter boards. Auto configuration code determines if the adapter is present at the configured address and what types of logical devices are configured on it.

CONFIGURATION

The driver attempts to initialize itself in accordance with the information found in the configuration file, /kernel/drv/csa.conf and with the information recorded in the EISA NVRAM. Each controller can support up to eight logical devices. The number and sizes of the logical devices are specified via the Compaq EISA Configuration Utility (ECU).
The user-configurable items in csa.conf are:
product_id
The EISA product ID and mask values which the controller will use to detect the presence of a supported SMART controller board. This property is a comma separated list of ID and mask values. Currently only the SMART board is supported. Although this property can be modified to include the product IDs of the older IDA , IDA-2 and IAES boards, those boards are not officially supported.
nccbs
The number of buffers which the driver should allocate to each controller board. The value specified should be between 16 and 255 .

FILES

/kernel/drv/csa.conf
configuration file for csa.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
dbri(7D)

NAME

dbri - Dual Basic Rate ISDN and audio Interface

DESCRIPTION

The dbri device uses the T5900FC Dual Basic Rate ISDN Interface (DBRI) and Multimedia Codec chips to implement the audio device interface. This interface is described fully in the audio(7I) manual page.
Applications that open /dev/audio may use the AUDIO_GETDEV ioctl to determine which audio device is being used. The dbri driver will return the string "SUNW,dbri" in the name field of the audio_device structure. The version field will contain "e" and the config field will contain one of the following values: "isdn_b" on an ISDN B channel stream, "speakerbox" on a /dev/audio stream associated with a SpeakerBox, and lastly "onboard1" on a /dev/audio stream associated with the onboard Multimedia Codec.
The AUDIO_SETINFO ioctl controls device configuration parameters. When an application modifies the record.buffer_size field using the AUDIO_SETINFO ioctl, the driver will constrain it to be non-zero and a multiple of 16 bytes, up to a maximum of 8176 bytes.

Audio Interfaces

The SpeakerBox audio peripheral is available for connection to the SpeakerBox Interface (SBI) port of most dbri equipped systems and provides an integral monaural speaker as well as stereo line out, stereo line in, stereo headphone, and monaural microphone connections. The headset output level is adequate to power most headphones, but may be too low for some external speakers. Powered speakers or an external amplifier may be used with both the headphone and line out ports.
SPARCstation LX systems have the Multimedia Codec integrated onto the CPU board of the machine thus giving users the option of using it or using a SpeakerBox plugged into the AUI/Audio port on the back panel. When using the "onboard" Codec, the microphone and headphone ports are located on the system back panel - there are no Line In or Line Out ports available for this configuration. In addition, the headphone and microphone ports do not have the input detection circuitry to determine whether or not there is currently headphones or a microphone plugged in. If a SpeakerBox is plugged in when the machine is first rebooted and reconfigured, or upon the first access of the audio device, it will be used, otherwise the onboard Codec will be used.
The Sun Microphone is recommended for normal desktop audio recording. When the Sun Microphone is used in conjunction with the SpeakerBox, the microphone battery is bypassed. Other audio sources may be recorded by connecting their line output to the SpeakerBox line input (audio sources may also be connected from their headphone output if the volume is adjusted properly).

ISDN Interfaces

The DBRI controller offers two Basic Rate ISDN (BRI) interfaces. One is a BRI Terminal Equipment (TE) interface and the other is a BRI Network Termination (NT) interface.
The NT connector is switched by a relay so that when system power is not available or when software is not accessing the NT port, the TE and NT connectors are electrically connected and devices plugged into the NT port will be on the same BRI passive bus.

Audio Data Formats for the Multimedia

The dbri device supports the audio formats listed in the following table. When the device is open for simultaneous play and record, the input and output data formats must match.

Codec/SpeakerBox

Supported Audio Data Formats
Sample Rate     Encoding      Precision  Channels
 8000 Hz     .-law or A-law      8          1
 9600 Hz     .-law or A-law      8          1
 11025 Hz    .-law or A-law      8          1
 16000 Hz    .-law or A-law      8          1
 18900 Hz    .-law or A-law      8          1
 22050 Hz    .-law or A-law      8          1
 32000 Hz    .-law or A-law      8          1
 37800 Hz    .-law or A-law      8          1
 44100 Hz    .-law or A-law      8          1
 48000 Hz    .-law or A-law      8          1
 8000 Hz         linear         16        1 or 2
 9600 Hz         linear         16        1 or 2
 11025 Hz        linear          16       1 or 2
 16000 Hz        linear          16       1 or 2
 18900 Hz        linear          16       1 or 2
 22050 Hz        linear          16       1 or 2
 32000 Hz        linear          16       1 or 2
 37800 Hz        linear          16       1 or 2
 44100 Hz        linear          16       1 or 2
 48000 Hz        linear          16       1 or 2

Audio Data Formats for BRI Interfeces

ISDN channels implement a subset of audio semantics. The preferred ioctls for querying or setting the format of a BRI channel are ISDN_GET_FORMAT, ISDN_SET_FORMAT, and ISDN_SET_CHANNEL .In particular, there is no audio format described in audio(7I) that covers HDLC or transparent data. The dbri driver maps HDLC and transparent data to AUDIO_ENCODING_NONE .ISDN D-channels are always configured for HDLC encoding of data. The programmer should interpret an encoding value of
AUDIO_ENCODING_NONE as an indication that the fd is not being used to transfer audio data.
B-channels can be configured for .-law, A-law, or HDLC encoding of data. The .-law and A-law formats are always at 8000 Hz, 8-bit, mono. Although a BRI H-channel is actually 16 bits wide at the physical layer and the 16-bit sample occurs at 8 kHz, the HDLC encoding always presents the data in 8-bit quantities. Therefore, 56 bit-per-second (bps), 64 bps, and 128 bps formats are all presented to the programmer as 8-bit wide, mono, AUDIO_ENCODING_NONE format streams at different sample rates. A line rate of 56kbps results in a 8-bit sample rate of 7000 Hz. If the bit stuffing and un-stuffing of HDLC were taken into account, the data rate would be slightly less.
For the sake of compatibility, AUDIO_GETINFO will return one of the following on a ISDN channel:
BRI Audio Data Formats
Sample Rate           Encoding             Precision  Channels
 8000 Hz           .-law or A-law             8          1
     -       AUDIO_ENCODING_NONE              -           -
ISDN_GET_FORMAT will return one of the following for an ISDN channel:
BRI Audio Data Formats
            Mode     Sample Rate   Encoding   Precision  # Ch   Available on
            HDLC       2000 Hz      NONE          8        1         D
            HDLC       7000 Hz      NONE          8        1        B1,B2
            HDLC       8000 Hz      NONE          8        1        B1,B2
            HDLC      16000 Hz      NONE          8        1        B1,B2
           TRANS      8000 Hz       .-law        8        1        B1,B2
           TRANS      8000 Hz       A-law        8        1        B1,B2
           TRANS      8000 Hz       NONE         8        1        B1,B2
           TRANS      8000 Hz       NONE         16       1       B1 only
In the previous table, HDLC = ISDN_MODE_HDLC ,TRANS = ISDN_MODE_TRANSPARENT .

Audio Ports

Audio ports are not relevant to ISDN D or B channels.
The record.avail_ports and play.avail_ports fields of the audio_info structure report the available input and output ports. The dbri device supports two input ports, selected by setting the record.port field to either AUDIO_MICROPHONE or AUDIO_LINE_IN . The play.port field may be set to any combination of AUDIO_SPEAKER ,AUDIO_HEADPHONE , and AUDIO_LINE_OUT by OR'ing the desired port names together. As noted above, when using the onboard Multimedia Codec on the SPARCstation LX, the Line In and Line Out ports are not available.

Sample Granularity

Since the dbri device manipulates buffers of audio data, at any given time the reported input and output sample counts will vary from the actual sample count by no more than the size of the buffers it is transferring. Programs should, in general, not rely on absolute accuracy of the play.samples and record.samples fields of the audio_info structure.

Audio Status Change Notification

As described in audio(7I), it is possible to request asynchronous notification of changes in the state of an audio device. The DBRI driver extends this to the ISDN B channels by sending the signal up the data channel instead of the control channel. Asynchronous notification of events on a B-channel only occurs when the channel is in a transparent data mode. When the channel is in HDLC mode, no such notification will take place.

ERRORS

In addition to the errors described in audio(7I), an open( ) will fail if:
ENODEV
The driver is unable to communicate with the SpeakerBox, possibly because it is currently not plugged in.

FILES

The physical device names are very system dependent and are rarely used by programmers. For example:
/devices/sbus@1,f8000000/SUNW,DBRIe@1,10000:te,b2.
The programmer should instead use the generic device names listed below:
/dev/audio
- symlink to the system's primary audio device, not necessarily a dbri based audio device
/dev/audioctl
- control device for the above audio device
/dev/sound/0*
- represents the first audio device on the system and is not
necessarily based on dbri or SpeakerBox
/dev/sound/0
- first audio device in the system
/dev/sound/0ctl
- audio control for above device
/dev/isdn/0/*
- represents the first ISDN device on the system and any associated interfaces. This device is not necessarily based on dbri.
/dev/isdn/0/te/mgt
- TE management device
/dev/isdn/0/te/d
- TE D-channel
/dev/isdn/0/te/b1
- TE B1-channel
/dev/isdn/0/te/b2
- TE B2-channel
/dev/isdn/0/nt/mgt
- NT management device
/dev/isdn/0/nt/d
- NT D-channel
/dev/isdn/0/nt/b1
- NT B1-channel
/dev/isdn/0/nt/b2
- NT B2-channel
/dev/isdn/0/aux/0
- SpeakerBox or onboard Multimedia Codec
/dev/isdn/0/aux/0ctl
- Control device for SpeakerBox or onboard Multimedia Codec
/usr/demo/SOUND
- audio demonstration programs and other files

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSPARC
The DBRI Multimedia Codec, and SpeakerBox are available on SPARCstation 10 and LX systems.
SPARCstation 10SX and SPARCstation 20 systems have the Multimedia Codec integrated onto the CPU board of the machine.
This hardware may or may not be available on future systems from Sun Microsystems Computer Corporation.
There are new configurations for the SX10SX and Gypsy machines. The SS10BSX looks like a speakerbox but does not have auto-detection of the Headphone and Microphone ports. The Gypsy claims to be "onboard" but does have line in and line out ports.

SEE ALSO

ioctl(2), attributes(5), audio(7I), isdnio(7I), streamio(7I)
AT&T Microelectronics data sheet for the T5900FC Sun Dual Basic Rate ISDN Interface.
Crystal Semiconductor, Inc., data sheet for the CS4215 16-Bit, 48 kHz, Multimedia Audio Codec Publication number DS76PP5.

NOTES

Due to hardware restrictions, it is impossible to reduce the record gain to 0. A valid input signal is still received at the lowest gain setting the Multimedia Codec allows. For security reasons, the dbri driver disallows a record gain value of 0. This is to provide feedback to the user that such a setting is not possible and that a valid input signal is still being received. An attempt to set the record gain to 0 will result in the lowest possible non-zero gain. The audio_info structure will be updated with this value when the AUDIO_SETINFO ioctl returns.

BUGS

When a DBRI channel associated with the SpeakerBox Interface underruns, DBRI may not always repeat the last sample but instead could repeat more than one sample. This behavior can result in a tone being generated by an audio device connected to the SBI port.
Monitor STREAMs connected to a B1 channel on either the TE or NT interface do not work because of a DBRI hardware problem. The device driver disallows the creation of such monitors.
display(7D)

NAME

display - system console display

DESCRIPTION

display is a component of the kd driver, which is comprised of the display and keyboard drivers.
Solaris for x86 normally uses a windowed environment. The character-based display facilities offered by the display section of the kd driver are supposed to be used only until the windowing system takes over. Currently, any VGA adapter can be used to boot the system, but the windows server requires an SVGA or 8514 adapter.
See the supported hardware list in the Hardware Compatibility List for Solaris 2.6 (Intel Platform Edition) for the full list of tested adapters.

FILES

/dev/console

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), console(7D), keyboard(7D)
Hardware Compatibility List for Solaris 2.6 (Intel Platform Edition)
Writing Device Drivers
dkio(7I)

NAME

dkio - disk control operations

SYNOPSIS

#include <sys/dkio.h>
#include <sys/vtoc.h>

DESCRIPTION

Disk drivers support a set of ioctl(2) requests for disk controller, geometry, and partition information. Basic to these ioctl( ) requests are the definitions in <sys/dkio.h>.

IOCTLS

The following ioctl( ) requests set and/or retrieve the current disk controller, partitions, or geometry information on all architectures:
DKIOCINFO
The argument is a pointer to a dk_cinfo structure (described below). This structure tells the type of the controller and attributes about how bad-block processing is done on the controller.
/*
* Structures and definitions for disk I/O control commands
* /
#define DK_DEVLEN
16
/* device name max length, * /
                             /* including unit # and NULL * /
/*
* Used for controller info
* /
struct dk_cinfo {
        char     dki_cname[DK_DEVLEN ]; /* controller name (no unit #)* /
        u_short  dki_ctype;                   /* controller type * /
        u_short  dki_flags;                    /* flags * /
        u_short  dki_cnum;                    /* controller number * /
        u_int    dki_addr;                    /* controller address * /
        u_int    dki_space;                   /* controller bus type * /
        u_int    dki_prio;                    /* interrupt priority * /
        u_int    dki_vec;                     /* interrupt vector * /
        char     dki_dname[DK_DEVLEN ]; /* drive name (no unit #) * /
        u_int    dki_unit;                    /* unit number * /
        u_int    dki_slave;                   /* slave number * /
        u_short  dki_partition;               /* partition number * /
        u_short  dki_maxtransfer;             /* maximum transfer size * /
                                              /* in DEV_BSIZE * /
};
/*
* Controller types
* /
#define DKC_UNKNOWN
0
#define DKC_CDROM               1                 /* CD-ROM, SCSI or
                                                   otherwise * /
#define DKC_WDC2880             2
#define DKC_XXX_0               3                 /* unassigned * /
#define DKC_XXX_1               4                 /* unassigned * /
#define DKC_DSD5215             5
#define DKC_XY450               6
#define DKC_ACB4000             7
#define DKC_MD21                8
#define DKC_XXX_2               9                 /* unassigned * /
#define DKC_NCRFLOPPY           10
#define DKC_XD7053              11
#define DKC_SMSFLOPPY           12
#define DKC_SCSI_CCS            13                /* SCSI CCS compatible * /
#define DKC_INTEL82072          14                /* native floppy chip * /
#define DKC_PANTHER             15
#define DKC_SUN_IPI1            DKC_PANTHER       /* Sun Panther * /
                                                 /* VME/IPI controller * /
#define DKC_MD                  16                /* meta-disk (virtual-disk) * /
                                                 /* driver * /
#define DKC_CDC_9057            17                /* CDC 9057-321 (CM-3) * /
                                                 /* IPI String Controller * /
#define DKC_FJ_M1060            18                /* Fujitsu/Intellistor * /
                                                 /* IM1060 PI-3 SC * /
#define DKC_INTEL82077          19                /* 82077 floppy disk * /
                                                 /* controller * /
#define DKC_DIRECT              20                /* Intel direct attached * /
                                                 /* device (IDE) * /
#define DKC_PCMCIA_MEM          21                /* PCMCIA memory disk-like * /
                                                 /* type * /
#define DKC_PCMCIA_ATA          22                /* PCMCIA AT Attached type * /
/*
* Sun reserves up through 1023
* /
#define DKC_CUSTOMER_BASE           1024
/*
* Flags
* /
#define DKI_BAD144           0x01   /* use DEC std 144 bad sector fwding * /
#define DKI_MAPTRK           0x02   /* controller does track mapping * /
#define DKI_FMTTRK           0x04   /* formats only full track at a time * /
#define DKI_FMTVOL           0x08   /* formats only full volume * /
                                   /* at a time* /
#define DKI_FMTCYL           0x10   /* formats only full cylinders * /
                                   /* at a time* /
#define DKI_HEXUNIT          0x20   /* unit number printed as 3 hex * /
/* digits * /
#define DKI_PCMCIA_PFD
0x40
/* PCMCIA pseudo-floppy memory card * /
DKIOCGAPART The argument is a pointer to a dk_allmap structure (described below).
This ioctl( ) gets the controller's notion of the current partition table for disk drive.
DKIOCSAPART The argument is a pointer to a dk_allmap structure (described below).
This ioctl( ) sets the controller's notion of the partition table without changing the disk itself.
/*
* Partition map (part of dk_label)
* /
struct dk_map {
        daddr_t dkl_cylno;    /* starting cylinder * /
        daddr_t dkl_nblk;     /* number of blocks * /
};
/*
* Used for all partitions
* /
struct dk_allmap {
        struct dk_map    dka_map[NDKMAP ];
};
DKIOCGGEOM The argument is a pointer to a dk_geom structure (described below).
This ioctl( ) gets the controller's notion of the current geometry of the disk drive.
DKIOCSGEOM
The argument is a pointer to a dk_geom structure (described below). This ioctl( ) sets the controller's notion of the geometry without changing the disk itself.
DKIOCGVTOC
The argument is a pointer to a vtoc structure (described below). This ioctl( ) returns the device's current VTOC (volume table of contents).
DKIOCSVTOC
The argument is a pointer to a vtoc structure (described below). This ioctl( ) changes the VTOC associated with the device.
struct partition {
        ushort     p_tag;     /* ID tag of partition * /
        ushort     p_flag;     /* permission flags * /
        daddr_t    p_start;   /* start sector of partition * /
        long       p_size;    /* # of blocks in partition * /
};
If DKIOCSVTOC is used with a floppy diskette, the p_start field must be the first sector of a cylinder. Multiply the number of heads by the number of sectors per track to compute the number of sectors per cylinder.
        struct vtoc {
           unsigned long v_bootinfo[3];                   /* info needed * /
                                                           /* by mboot * /
                                                           /* (unsupported) * /
           unsigned long v_sanity;                        /* to verify vtoc * /
                                                           /* sanity * /
           unsigned long v_version;                       /* layout version * /
           char            v_volume[LEN_DKL_VVOL ];       /* volume name * /
           ushort          v_sectorsz;                    /* sector size in * /
                                                           /* bytes * /
           ushort          v_nparts;                      /* number of * /
                                                           /* partitions * /
           unsigned long v_reserved[10];                  /* free space * /
           struct partition v_part[V_NUMPAR ];            /* partition * /
                                                           /* headers* /
           time_t          timestamp[V_NUMPAR ];          /* partition * /
                                                           /* timestamp * /
                                                           /* (unsupported) * /
           char            v_asciilabel[LEN_DKL_ASCII ]; /* compatibility * /
        };
/*
        * Partition permission flags
        * /
#define V_UNMNT
0x01
/* Unmountable partition * /
        #define V_RONLY        0x10    /* Read only * /
/*
        * Partition identification tags
        * /
#define V_UNASSIGNED
0x00
/* unassigned partition * /
        #define V_BOOT               0x01    /* Boot partition * /
        #define V_ROOT               0x02    /* Root filesystem * /
        #define V_SWAP               0x03    /* Swap filesystem * /
        #define V_USR                0x04    /* Usr filesystem * /
        #define V_BACKUP             0x05    /* full disk * /
        #define V_VAR                0x07    /* Var partition * /
        #define V_HOME               0x08    /* Home partition * /
        #define V_ALTSCTR            0x09    /* Alternate sector partition * /
DKIOCEJECT
This ioctl( ) requests the disk drive to eject its disk, if that drive supports removable media.
DKIOCPARTINFO
The argument is a pointer to a part_info structure (described below). This ioctl( ) gets the driver's notion of the size and extent of the partition or slice indicated by the file descriptor argument.
/*
        * Used by applications to get partition or slice information
        * /
struct part_info {
                daddr_t    p_start;
                int        p_length;
        };
DKIOCREMOVABLE
The argument to this ioctl( ) is an integer. After successful completion, this ioctl( ) will set that integer to a non-zero value if the drive in question has removable media. If the media is not removable that integer will be set to 0 .
DKIOCSTATE
This ioctl( ) blocks until the state of the drive, inserted or ejected, is changed. The argument is a pointer to a dkio_state, enum, whose possible enumerations are listed below. The initial value should be either the last reported state of the drive, or DKIO_NONE . Upon return, the enum pointed to by the argument is updated with the current state of the drive.
        enum dkio_state {
                DKIO_NONE ,         /* Return disk's current state * /
                DKIO_EJECTED ,      /* Disk state is 'ejected' * /
                DKIO_INSERTED       /* Disk state is 'inserted' * /
        };
DKIOCLOCK
This ioctl( ) requests the disk drive to lock the door, for those devices with removable media.
DKIOCUNLOCK
This ioctl( ) requests the disk drive to unlock the door, for those devices with removable media.

x86 Only

The following ioctl( ) requests set and/or retrieve the current disk controller, partitions, or geometry information on x86 architectures:
DKIOCG_PHYGEOM
                The argument is a pointer to a dk_geom structure (described below).
                This ioctl( ) gets the driver's notion of the physical geometry of the disk
                drive. It is functionally identical to the DKIOCGGEOM ioctl( ).
DKIOCG_VIRTGEOM
The argument is a pointer to a dk_geom structure (described below). This ioctl( ) gets the controller's (and hence the driver's) notion of the virtual geometry of the disk drive. Virtual geometry is a view of the disk geometry maintained by the firmware in a host bus adapter or disk controller.
/*
        * Definition of a disk's geometry
        * /
struct dk_geom {
                unsigned short    dkg_ncyl;               /* # of data * /
                                                          /* cylinders * /
                unsigned short    dkg_acyl;               /* # of alternate* /
                                                          /* cylinders * /
                unsigned short    dkg_bcyl;               /* cyl offset (for * /
                                                          /* fixed head area) * /
                unsigned short    dkg_nhead;              /* # of heads * /
                unsigned short    dkg_obs1;               /* obsolete * /
                unsigned short    dkg_nsect;              /* # of sectors * /
                                                          /* per track * /
                unsigned short    dkg_intrlv;             /* interleave factor * /
                unsigned short    dkg_obs2;               /* obsolete * /
                unsigned short    dkg_obs3;               /* obsolete * /
                unsigned short    dkg_apc;                /* alternates per * /
                                                          /* cyl (SCSI only) * /
                unsigned short    dkg_rpm;                /* revolutions per min* /
                unsigned short    dkg_pcyl;               /* # of physical * /
                                                          /* cylinders * /
                unsigned short    dkg_write_reinstruct;   /* # sectors to * /
                                                          /* skip, writes * /
                unsigned short    dkg_read_reinstruct;    /* # sectors to * /
                                                          /* skip, reads * /
                unsigned short    dkg_extra[7];           /* for compatible* /
                                                          /* expansion * /
        };
#define dkg_gap1
dkg_extra[0]
/* for application * /
                                             /* compatibility * /
        #define dkg_gap2      dkg_extra[1]    /* for application * /
                                             /* compatibility * /
DKIOCADDBAD
This ioctl( ) forces the driver to re-examine the alternates slice and rebuild the internal bad block map accordingly. It should be used whenever the alternates slice is changed by any method other than the addbadsec(1M) or format(1M) utilities.

SEE ALSO

format(1M), ioctl(2), cdio(7I), fdio(7I) hdio(7I), ipi(7D), sd(7D), xd(7D), xy(7D)

x86 Only

addbadsec(1M), cmdk(7D)
dlpi(7P)

NAME

dlpi - Data Link Provider Interface

SYNOPSIS

#include <sys/dlpi.h>

DESCRIPTION

SunOS STREAMS -baseddevice drivers wishing to support the STREAMS TCP/IP and other STREAMS -basednetworking 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 is intended to support Ethernet, X.25 LAPB, SDLC, ISDN LAPD, CSMA/CD, FDDI, token ring, token bus, Bisync, and other datalink-level protocols.
The interface specifies access to the data link service provider in the form of M_PROTO and M_PCPROTO type STREAMS messages and does not define a specific protocol implementation. The interface defines the syntax and semantics of primitives exchanged between the data link user and the data link provider to attach a physical device with physical-level address to a stream, bind a datalink-level address to the stream, get implementation-specific information from the data link provider, exchange data with a peer data link user in one of three communication modes (connection, connectionless, acknowledged connectionless), enable/disable multicast group and promiscuous mode reception of datalink frames, get and set the physical address associated with a stream, and several other operations.
For details on this interface refer to the <sys/dlpi.h> header and to the STREAMS DLPI Specification, 800-6915-01.

FILES

Files in or under /dev.

SEE ALSO

ie(7D), le(7D)
dnet(7D)

NAME

dnet - Ethernet driver for DEC 21040, 21041, 21140 Ethernet cards

SYNOPSIS

/dev/dnet

DESCRIPTION

The dnet Ethernet driver is a multi-threaded, loadable, clonable, STREAMS GLD driver. Multiple controllers installed within the system are supported by the driver. The dnet driver functions include controller initialization, frame transmit and receive, functional addresses, promiscuous and multicast support, and error recovery and reporting.

APPLICATION PROGRAMMING

The cloning character-special device, /dev/dnet, is used to access all DEC 21040/21041/21140 devices installed in the system.

INTERFACE

The dnet driver is dependent on /kernel/misc/gld, a loadable kernel module that provides the dnet driver with the DLPI and STREAMS functionality required of a LAN driver. See gld (7D)for more details on the primatives supported by the driver.
The device is initialized on the first attach and de-initialized (stopped) on the last detach.
The values returned by the driver in the DL_INFO_ACK primitive in response to a DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU - defined in <sys/ethernet.h>).
The minimum SDU is 0 .
The DLSAP address length is 8 .
The MAC type is DL_ETHER .
The sap length value is -2 ,meaning the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The broadcast address value is the Ethernet/IEEE broadcast address (FF:FF:FF:FF:FF:FF).
Once in the DL_ATTACHED state, the user must send a DL_BIND_REQ to associate a particular Service Access Point (SAP) with the stream.

CONFIGURATION

The /plaform/i86pc/kernel/drv/dnet.conf file supports the following options:
fulldup
For full duplex operation use fulldup=1, for half duplex use fulldup=0. Half-duplex operation gives better results on older 10mbit networks.
mode
For 10mbit operation use mode=10, for 100mbit operation use mode=100. Certain 21140 based cards will operate at either
speed. Use the mode property to override the 100mbit default in this case.

FILES

/dev/dnet
character special device
/plaform/i86pc/kernel/drv/dnet.conf
dnet configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), gld (7D)streamio(7I)
Writing Device Drivers
STREAMS Programming Guide
Network Interfaces Programmer's Guide
dpt(7D)

NAME

dpt - DPT 2011, 2012, 2021, 2022, 2122, 2024, 2124, 3021, 3222, and 3224 controllers

SYNOPSIS

ISA, EISA: dpt@ioaddr,0
PCI: dpt@reg

DESCRIPTION

The dpt module provides low-level interface routines between the common disk/tape I/O subsystem and the DPT ISA bus master 2011 and 2021 Small Computer System Interface (SCSI) controllers, the DPT EISA 2012, 2022, and 2122 SCSI controllers, the DPT PCI 2024 and 2124 SCSI controllers, and the DPT SCSI RAID controllers: 3021 (ISA) , 3222 (EISA), and 3224 (PCI) .
The dpt module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and what types of devices are attached to it. If a memory cache module is installed on the DPT board, this cache will be flushed to disk by the dpt driver module when the system is shut down by the system administrator.

FILES

/platform/i86pc/kernel/drv/dpt.conf
Configuration file for the dpt driver. There
are no user-configurable options in this file.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

sysbus(4), attributes(5)
dsa(7D)

NAME

dsa - low-level module for Dell SCSI Array Controller (DSA)

DESCRIPTION

The dsa module provides low-level interface routines between the common disk/tape I/O subsystem and the Dell EISA bus master controller. The dsa module can be configured for disk and raid disks on up to four host adapter boards. These disks are called composite disks in Dell configuration software. Auto configuration code determines if the adapter is present at the configured address and what devices are attached to it. Non composite drives attached to the bus of a DSA controller are accessed through Adaptec 1540 emulation. See the entry aha(7D).

Board Configuration and Auto

The Dell EISA configuration utility must be run to properly initialize access to the controller. One controller should have the adapter bios enabled. If the DSA controller is used to read the Solaris CD disk for installation, Adaptec 1540A emulation should be enabled.

Configuration

All hard drives accessible by the dsa driver must be configured by the Dell Array Manager software as composite drives. All raid levels supported by Dell are visible to the dsa driver. A controller can be in slots one through eight. If the DSA controller is used for Solaris x86 CD installation, the CD must be mapped at the proper target, which cannot be 0. The DSA controller is target 0 on the SCSI bus but should be set up to appear as target 7 in the emulation mappings.
The driver attempts to initialize itself in accordance with the information found in the configuration file, /kernel/drv/dsa.conf. There are no user configurable items in this file.

FILES

/kernel/drv/dsa.conf
configuration file for the dsa driver

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), aha(7D)

NOTES

Note that although the DSA controller is physically connected to SCSI devices, the interface to composite drives is that of a direct access disk "dadk." There is no way to send SCSI commands to composite drives on a DSA controller. Non composite devices (such as tape and CD) can not be accessed via the dsa driver.
ecpp(7D)

NAME

ecpp - IEEE 1284 ecp, nibble and centronics compatible parallel port driver

SYNOPSIS

#include <sys/types.h>
#include <fcntl.h>
#include <sys/ecppio.h>
fd = open("/dev/ecpp0", flags);

DESCRIPTION

The ecpp driver provides a bi-directional interface to IEEE 1284 compliant devices. The driver will operate in Centronics mode for non-IEEE 1284 compliant devices. An IEEE 1284 compliant peripheral device must operate at least in Compatibility mode and Nibble mode. The ecpp driver supports Compatibility, Nibble and ECP modes of operation as defined by IEEE 1284. Centronics and Compatibility modes of operation have identical physical characteristics. However, non-IEEE 1284 compliant devices will be logically defined as ECPP_CENTRONICS .IEEE 1284 devices that are in a similar mode will be logically defined as ECPP_COMPAT_MODE .ECPP_COMPAT_MODE operates in conjunction with ECPP_NIBBLE_MODE .The ecpp driver is an exclusive-use device. If the device has already been opened, subsequent opens fail with EBUSY .

Default Operation

Each time the ecpp device is opened, the device is marked as EBUSY and the configuration variables are set to their default values. The write_timeout period is set to 60 seconds. The driver sets the mode variable according to the following algorithm: The driver initially attempts to negotiate the device into ECP mode. If this fails, the driver will attempt to negotiate into Nibble mode. If Nibble mode negotiation fails, the driver will operate in Centronics mode. The application may attempt to negotiate the device into a specific mode or set the write_timeout values through the ECPPIOC_SETPARMS ioctl(2) call. In order for the negotiation to be successful, both the host workstation and the peripheral must support the requested mode.
The preferred mode of operation of an IEEE 1284 device is the bi-directional ECP mode. Nibble mode is a unidirectional backchannel mode. It utilizes a PIO method of transfer and consequently, is inefficient. For devices that primarly receive data from the workstation, such as printers, Nibble operation will have limited impact to system performance. Nibble mode should not be used for devices such as a scanner, that primarily send data to the workstation. Forward transfers under all modes are conducted through a DMA method of transfer.

Tunables

The default timeout for the ecpp device driver may be changed by adding the following line to the /etc/system file:
set ecpp:ecpp_def_timeout = value
See system(4) for more details.

Read/Write Operation

ecpp is a full duplex STREAMS device driver. While an application is writing to an IEEE 1284 compliant device, another thread may read from it. write(2) will return when all the data has been successfully transferred to the device.

Write Operation

write( ) returns the number of bytes successfully written to the stream head. If a failure occurs while a Centronics device is transfering data, the content of the status bits will be captured at the time of the error, and can be retrieved by the application program, using the ECPPIOC_GETERR ioctl( ) call. The captured status information will be overwritten each time an attempted transfer or a ECPPIOC_TESTIO ioctl( ) occurs.
Intelligent IEEE 1284 compliant devices, such as Postscript printers, return error information through a backchannel. This data may be retrieved with the read (2)call.

Read Operation

If a failure or error condition occurs during a read (2),the number of bytes successfully read is returned (short read). When attempting to read the port that has no data currently available, read( ) returns 0 if O_NDELAY is set. If O_NONBLOCK is set, read( ) returns -1 and sets errno to EAGAIN .If O_NDELAY and O_NONBLOCK are clear, read( ) blocks until data become available.

IOCTLS

The following ioctl(2) calls are supported:
ECPPIOC_GETPARMS
Get current transfer parameters.
The argument is a pointer to a struct ecpp_transfer_parms. See below for a description of the elements of this structure. If no parameters have been configured since the device was opened, the structure will be set to its default configuration. See Default Operation above.
ECPPIOC_SETPARMS
Set transfer parameters.
The argument is a pointer to a struct ecpp_transfer_parms. If a parameter is out of range, EINVAL is returned. If the peripheral or host device can not support the requested mode, EPROTONOSUPPORT is returned. See below for a description of ecpp_transfer_parms and its valid parameters.
Transfer Parameters Structure
This structure is defined in <sys/ecppio.h>.
struct ecpp_transfer_parms {
 int  write_timeout;
 int  mode;
};
The write_timeout field is set to ECPP_W_TIMEOUT_DEFAULT. The write_timeout field specifies how long the driver will wait for the peripheral to respond to a transfer request. The value must be greater than 0 and less than ECPP_MAX_TIMEOUT .Any other values are out of range.
The mode field reflects the IEEE 1284 mode that the parallel port is
currently configured to. The mode may be set to only one of the following bit values.
#define ECPP_CENTRONICS             0x1
#define ECPP_COMPAT_MODE            0x2
#define ECPP_NIBBLE_MODE            0x3
#define RESERVED                    0x4
#define ECPP_FAILURE_MODE           0x5
This command may set the mode value to ECPP_CENTRONICS , ECPP_COMPAT_MODE ,or ECPP_NIBBLE_MODE .All other values are not valid. If the requested mode is not supported, ECPPIOC_SETPARMS will return EPROTONOSUPPORT .Under this circumstance,
ECPPIOC_GETPARMS will return to its orignal mode. If a non-recoverable IEEE 1284 error occurs, the driver will be set to ECPP_FAILURE_MODE. For instance, if the port is not capable of returning to its orignal mode, ECPPIOC_GETPARMS will return ECPP_FAILURE_MODE.
BPPIOC_TESTIO
              Tests the transfer readiness of ECPP_CENTRONICS or
              ECPP_COMPAT_MODE devices.
If the current mode of the port is ECPP_CENTRONICS or
ECPP_COMPAT_MODE ,this command determines if write(2) would succeed. If it is not one of these modes, EINVAL is returned. BPPIOC_TESTIO determines if a write(2) would succeed by checking the open flag and status pins. If any of the status pins are set, a transfer would fail. If a transfer would succeed, zero is returned. If a transfer would fail, -1 is returned, and errno is set to EIO ,and the state of the status pins is captured. The captured status can be retrieved using the BPPIOC_GETERR ioctl(2) call. Note that the timeout_occurred and bus_error fields will never be set by this ioctl(2). BPPIOC_TESTIO and BPPIOC_GETERR are compatible to the ioctls specified in bpp(7). However, bus_error is not used in this interface.
BPPIOC_GETERR
Get last error status.
The argument is a pointer to a struct bpp_error_status. This structure is described below. This structure indicates the status of all the appropriate status bits at the time of the most recent error condition during a write( ) call, or the status of the bits at the most recent BPPIOC_TESTIO ioctl( ) call.
The timeout_occurred value is set when a timeout occurs during write( ). bus_error is not used in this interface.
pin_status indicates possible error conditions under ECPP_CENTRONICS or ECPP_COMPAT_MODE .Under these modes, the state of the status pins
will indicate the state of the device. For instance, many Centronics printers lower the nErr signal when a paper jam occurs. The behavior of the status pins depends on the device. As defined in the IEEE 1284 Specification, status signals do not represent the error status of ECP devices. Error information is formatted by a printer specific protocol such as PostScript, and is returned through the backchannel.
Error Status Structure
struct bpp_error_status is defined in the include file <sys/bpp_io.h>. The valid bits for pin_status are presented below. A set bit indicates that the associated pin is asserted. For example, if BPP_ERR_ERR is set, nErr is asserted.
struct bpp_error_status {
 char timeout_occurred; /* 1=timeout * /
 char bus_error;     /* not used * /
 u_char pin_status;  /*
                                       * status of pins
              * which could cause
              * error.
              * /
};
/* pin_status values * /
#define BPP_ERR_ERR        0x01 /* nErr=0 * /
#define BPP_SLCT_ERR        0x02 /* Select=1 * /
#define BPP_PE_ERR        0x04 /* PE =1 * /
#define BPP_BUSY_ERR        0x40 /* Busy = 1 * /

ERRORS

EBADF
The device is opened for write-only access and a read is attempted, or the device is opened for read-only access and a write is attempted.
EBUSY
The device has been opened and another open is attempted.
An attempt has been made to unload the driver while one of the units is open.
EINVAL
A ECPPIOC_SETPARMS ioctl( ) is attempted with an out of range value in the ecpp_transfer_parms structure.
A ECPPIOC_SETREGS ioctl( ) is attempted with an invalid value in the ecpp_regs structure.
An ioctl( ) is attempted with an invalid value in the command argument. An invalid command argument is received from the vd driver during modload(1M), modunload(1M).
EIO
The driver encountered a bus error when attempting an access.
A read or write does not complete properly, due to a peripheral error or a transfer timeout.
ENXIO
The driver has received an open request for a unit for which the attach failed. The driver has received a write request for a unit which has an active peripheral error.

FILES

/dev/ecpp0
1284 compatible and ecp mode parallel port device.

SEE ALSO

ioctl(2), read (2),write(2), system(4), streamio(7I)
eepro(7D)

NAME

eepro - Intel EtherExpress-Pro Ethernet device driver

SYNOPSIS

/dev/eepro

DESCRIPTION

The eepro Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over Intel EtherExpress-Pro Ethernet controllers. The EtherExpress-Pro Ethernet adapter is based on the Intel 82595TX high integration controller. Multiple EtherExpress-Pro controllers installed within the system are supported by the driver.
The eepro driver provides basic support for the EtherExpress-Pro hardware. Functions including chip initialization, frame transmit and receive, multicast and "promiscuous" support, and error recovery and reporting. It also supports an ioctl to perform a time domain reflectometry test (i.e. detect open or short circuits on the link). Refer to IOCTLS below.

APPLICATION PROGRAMMING

The cloning, character-special device /dev/eepro is used to access all EtherExpress-Pro devices installed within the system.

INTERFACE

eepro and DLPI

The eepro driver is dependent on /kernel/misc/gld, a loadable kernel module that provides the eepro driver with the DLPI and STREAMS functionality required of a LAN driver. See gld (7D)for more details on the primatives supported by the driver.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU - defined in <sys/ethernet.h>).
The minimum SDU is 0 . The driver will pad to the mandatory 60-byte minimum packet size.
The dlsap address length is 8 .
The Media Access Control (MAC) type is DL_ETHER .
The sap length value is -2 ,meaning the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The broadcast address value is Ethernet/IEEE broadcast address (FF:FF:FF:FF:FF:FF).

CONFIGURATION

Auto-detect of the media type is supported and the board need not be explicitly configured for which media connector it is using. It is important to ensure that there are no conflicts between the board's I/O port or IRQ level and other hardware installed in the system.

FILES

/dev/eepro
eepro character special device
/kernel/drv/eepro.conf
configuration file of eepro driver

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), gld (7D)
eha(7D)

NAME

eha - low-level module for Adaptec 174x EISA host bus adapter

DESCRIPTION

The eha module provides low-level interface routines between the common disk/tape io subsystem and the Adaptec EISA 174x SCSI (Small Computer System Interface) controllers. The eha module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and what types of devices are attached to it.

Board Configuration and Auto

The driver attempts to initialize itself in accordance with the information found in the configuration file, /kernel/drv/eha.conf. The only relevant user configurable item in this file is:

Configuration

io address "reg=0x1000,0,0"
        "ioaddr=0x1000"
The I/O address is 0x1000 times the EISA slot number. Hence, slot 1 is address 0x1000 and slot 8 is 0x8000.
Prior to installation, the 174x controller must be put into enhanced mode with the EISA configuration utility run under MS-DOS.
The default listing of the configuration file is as follows:
#
# primary controller [Settings for CD-ROM installation]
#
name="eha" class="sysbus" reg=0x1000,0,0
        ioaddr=0x1000;
# another controller example
#
name="eha" class="sysbus" reg=0x2000,0,0
        ioaddr=0x2000;
#
To speed boot, parameters in the configuration file may be commented out with a "#" in the first column for controllers that are not installed.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
el(7D)

NAME

el - 3COM 3C503 Ethernet device driver

SYNOPSIS

#include <sys/stropts.h>
#include <sys/ethernet.h>
#include <sys/dlpi.h>
#include <sys/gld.h>

DESCRIPTION

The el Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over 3COM 3C503 EtherLink II and EtherLink II/16 Ethernet controllers. The el driver is dependent on /kernel/misc/gld, a loadable kernel module that provides the el driver with the DLPI and STREAMS functionality required of a LAN driver. See gld (7D)for more details on the primatives supported by the driver.
Multiple EtherLink II controllers installed within the system are supported by the driver. The el driver provides basic support for the EtherLink II hardware. Functions include chip initialization, frame transmit and receive, multicast and "promiscuous" support, and error recovery and reporting.
The cloning, character-special device /dev/el is used to access all EtherLink II devices installed within the system.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU).
The minimum SDU is 0. The driver will pad to the mandatory 60-octet minimum packet size.
The dlsap address length is 8.
The MAC type is DL_ETHER .
The sap length value is -2, meaning the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The broadcast address value is Ethernet/IEEE broadcast address (FF:FF:FF:FF:FF:FF).

FILES

/dev/el
character special device

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), gld (7D)
elink(7D)

NAME

elink - 3COM 3C507 Ethernet device driver

SYNOPSIS

#include <sys/stropts.h>
#include <sys/ethernet.h>
#include <sys/dlpi.h>
#include <sys/gld.h>

DESCRIPTION

The elink Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over 3COM 3C507 EtherLink 16 Ethernet controllers. Multiple EtherLink 16 controllers installed within the system are supported by the driver. The elink driver provides basic support for the EtherLink 16 hardware. Functions include chip initialization, frame transmit and receive, multicast and "promiscuous" support, and error recovery and reporting.

APPLICATION PROGRAMMING

The cloning, character-special device /dev/elink is used to access all EtherLink 16 devices installed within the system.

INTERFACE

elink and DLPI

The elink driver is dependent on /kernel/misc/gld, a loadable kernel module that provides the elink driver with the DLPI and STREAMS functionality required of a LAN driver. See gld (7D)for more details on the primatives supported by the driver.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU ).
The minimum SDU is 0 . The driver will pad to the mandatory 60-octet minimum packet size.
The dlsap address length is 8 .
The MAC type is DL_ETHER .
The sap length value is -2 ,meaning the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The broadcast address value is Ethernet/IEEE broadcast address (FF:FF:FF:FF:FF:FF).

FILES

/dev/elink
character special device
/kernel/drv/elink.conf
elink configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), gld (7D)
elx(7D)

NAME

elx - 3COM EtherLink III Ethernet device driver

SYNOPSIS

#include <sys/stropts.h>
#include <sys/ethernet.h>
#include <sys/dlpi.h>
#include <sys/gld.h>

DESCRIPTION

The elx Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over the following 3COM ETHERLINK III Ethernet controllers. For x86 based systems: 3C509, 3C509B, 3C529 and 3C579 controllers. Multiple EtherLink III controllers installed within the system are supported by the driver. The elx driver provides basic support for the EtherLink III hardware. Functions include chip initialization, frame transmit and receive, multicast and "promiscuous" support, and error recovery and reporting.
The cloning, character-special device /dev/elx is used to access all EtherLink III devices installed within the system.
The elx driver is dependent on /kernel/misc/gld, a loadable kernel module that provides the elx driver with the DLPI and STREAMS functionality required of a LAN driver. See gld (7D)for more details on the primatives supported by the driver.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU ).
The minimum SDU is 0 . The driver will pad to the mandatory 60-octet minimum packet size.
The dlsap address length is 8 .
The MAC type is DL_ETHER .
The sap length value is -2 ,meaning the physical address component is followed immediately by a 2-byte sap component within the DLSAP address.
The broadcast address value is Ethernet/IEEE broadcast address (FF:FF:FF:FF:FF:FF).

FILES

/dev/elx
special character device
/platform/i86pc/kernel/drv/elx.conf
configuration file for elx driver

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), gld (7D)
esa(7D)

NAME

esa - low-level module for Adaptec 7770 based SCSI controllers

DESCRIPTION

The esa module provides low-level interface routines between the common disk/tape I/O system and SCSI (Small Computer System Interface) controllers based on the Adaptec AIC-7770 SCSI chip. These controllers include the Adaptec 2740 and 2840, as well as motherboards with an embedded AIC-7770 SCSI chip.
The esa module can be configured for disk and streaming tape support for one or more host adapter boards, each of which must be the sole initiator on a SCSI bus. Auto configuration code determines if the adapter is present at the configured address and what types of devices are attached to the adapter. Each controller may support one or two SCSI busses, depending on the manufacturer's implementation.

FILES

/kernel/drv/esa.conf
configuration file for the esa driver. There are no user-
configurable options in this file.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5)
esp(7D)

NAME

esp - ESP SCSI Host Bus Adapter Driver

SYNOPSIS

esp@sbus-slot,80000

DESCRIPTION

The esp Host Bus Adapter driver is a SCSA compliant nexus driver that supports the Emulex family of esp SCSI chips (esp100, esp100A, esp236, fas101, fas236).
The esp driver supports the standard functions provided by the SCSA interface. The driver supports tagged and untagged queuing, fast SCSI (on FAS esp's only), almost unlimited transfer size (using a moving DVMA window approach), and auto request sense; but it does not support linked commands.

CONFIGURATION

The esp driver can be configured by defining properties in esp.conf which override the global SCSI settings. Supported properties are: scsi-options, target<n>-scsi-options, scsi-reset-delay, scsi-watchdog-tick, scsi-tag-age-limit, scsi-initiator-id.
target<n>-scsi-options overrides the scsi-options property value for target<n>. <n> can vary from 0 to 7 .
Refer to scsi_hba_attach(9F) for details.

EXAMPLES

Create a file /kernel/drv/esp.conf and add this line:
scsi-options=0x78;
This will disable tagged queuing, fast SCSI, and Wide mode for all esp instances. To disable an option for one specific esp (refer to driver.conf(4)):
name="esp" parent="/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000"
   reg=0xf,0x800000,0x40
   target1-scsi-options=0x58
   scsi-options=0x178 scsi-initiator-id=6;
Note that the default initiator ID in OBP is 7 and that the change to ID 6 will occur at attach time. It may be preferable to change the initiator ID in OBP.
The above would set scsi-options for target 1 to 0x58 and for all other targets on this SCSI bus to 0x178 . The physical pathname of the parent can be determined using the /devices tree or following the link of the logical device name:
example# ls -l /dev/rdsk/c0t3d0s0
lrwxrwxrwx 1 root root 88 Aug 22 13:29 /dev/rdsk/c0t3d0s0 ->
../../devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/
       esp@f,800000/sd@3,0:a,raw
The register property values can be determined from prtconf(1M) output (-v option):
esp, instance #0
....
  Register Specifications:
Bus Type=0xf, Address=0x800000, Size=40
To set scsi-options more specifically per target:
target1-scsi-options=0x78;
device-type-scsi-options-list =
    "SEAGATE ST32550W", "seagate-scsi-options" ;
seagate-scsi-options = 0x58;
scsi-options=0x3f8;
The above would set scsi-options for target 1 to 0x78 and for all other targets on this SCSI bus to 0x378 except for one specific disk type which will have scsi-options set to 0x58.
scsi-options specified per target ID has the highest precedence, followed by scsi-options per device type. To get the inquiry string run probe-scsi or probe-scsi-all command at the ok prompt before booting the system.
Global (ie. for all esp instances) scsi-options per bus has the lowest precedence.
The system needs to be rebooted before the specified scsi-options take effect.

FILES

/kernel/drv/esp
ELF Kernel Module
/kernel/drv/esp.conf
Configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSBus-based systems with esp-based SCSI port and SSHA, SBE/S, FSBE/S, and DSBE/S SBus SCSI Host Adapter options

SEE ALSO

prtconf(1M), driver.conf(4), attributes(5), fas(7D), scsi_abort(9F), scsi_hba_attach(9F), scsi_ifgetcap(9F), scsi_reset(9F), scsi_sync_pkt(9F), scsi_transport(9F), scsi_device(9S), scsi_extended_sense(9S), scsi_inquiry(9S), scsi_pkt(9S)
Writing Device Drivers
OpenBoot Command Reference
ANSI Small Computer System Interface-2 (SCSI-2)
ESP Technical Manuals, QLogic Corp.

DIAGNOSTICS

The messages described below are some that may appear on the system console, as well as being logged.
The first four messages may be displayed while the esp driver is trying to attach; these messages mean that the esp driver was unable to attach. All of these messages are preceded by "esp%d", where "%d" is the instance number of the esp controller.
Device in slave-only slot
The SBus device has been placed in a slave-only slot and will not be accessible; move to non-slave-only SBus slot.
Device is using a hilevel intr
The device was configured with an interrupt level that cannot be used with this esp driver. Check the SBus device.
Unable to map registers
Driver was unable to map device registers; check for bad hardware. Driver did not attach to device; SCSI devices will be inaccessible.
Cannot find dma controller
Driver was unable to locate a dma controller. This is an auto-configuration error.
Disabled TQ since disconnects are disabled
        Tagged queuing was disabled because disconnects were disabled in scsi-options.
Bad clock frequency- setting 20mhz, asynchronous mode
Check for bad hardware.
Sync pkt failed
        Syncing a SCSI packet failed. Refer to scsi_sync_pkt(9F).
Slot %x: All tags in use!!!
The driver could not allocate another tag number. The target devices do not properly support tagged queuing.
Target %d.%d cannot alloc tag queue\n
The driver could not allocate space for tag queue.
Gross error in esp status (%x)
The driver experienced severe SCSI bus problems. Check cables and terminator.
Spurious interrupt
The driver received an interrupt while the hardware was not interrupting.
Lost state in phasemanage
The driver is confused about the state of the SCSI bus.
Unrecoverable DMA error during selection
The DMA controller experienced host SBus problems. Check for bad hardware.
Bad sequence step (0x%x) in selection
The esp hardware reported a bad sequence step. Check for bad hardware.
Undetermined selection failure
The selection of a target failed unexpectedly. Check for bad hardware.
>2 reselection IDs on the bus
Two targets selected simultaneously, which is illegal. Check for bad hardware.
Reconnect: unexpected bus free
A reconnect by a target failed. Check for bad hardware.
Timeout on receiving tag msg
Suspect target f/w failure in tagged queue handling.
Parity error in tag msg
A parity error was detected in a tag message. Suspect SCSI bus problems.
Botched tag
The target supplied bad tag messages. Suspect target f/w failure in tagged queue handling.
Parity error in reconnect msg's
The reconnect failed because of parity errors.
Target <n> didn't disconnect after sending <message>
The target unexpectedly did not disconnect after sending <message>.
No support for multiple segs
        The esp driver can only transfer contiguous data.
No dma window?
Moving the DVMA window failed unexpectedly.
No dma window on <type> operation
Moving the DVMA window failed unexpectedly.
Cannot set new dma window
Moving the DVMA window failed unexpectedly.
Unable to set new window at <address> for <type> operation
Moving the DVMA window failed unexpectedly.
Illegal dma boundary? %x
An attempt was made to cross a boundary that the driver could not handle.
Unwanted data out/in for Target <n>
The target went into an unexpected phase.
Spurious <name> phase from target <n>
The target went into an unexpected phase.
SCSI bus DATA IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus MESSAGE IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus STATUS phase parity error
The driver detected parity errors on the SCSI bus.
Premature end of extended message
An extended SCSI bus message did not complete. Suspect a target f/w problem.
Premature end of input message
A multibyte input message was truncated. Suspect a target f/w problem.
Input message botch
The driver is confused about messages coming from the target.
Extended message <n> is too long
The extended message sent by the target is longer than expected.
<name> message <n> from Target <m> garbled
Target <m> sent message <name> of value <n> which the driver did not understand.
Target <n> rejects our message <name>
Target <n> rejected a message sent by the driver.
Rejecting message <name> from Target <n>
The driver rejected a message received from target <n>
Cmd dma error
The driver was unable to send out command bytes.
Target <n> refused message resend
The target did not accept a message resend.
Two-byte message <name> <value> rejected
The driver does not accept this two-byte message.
Unexpected selection attempt
An attempt was made to select this host adapter by another initiator.
Polled cmd failed (target busy)
A polled command failed because the target did not complete outstanding commands within a reasonable time.
Polled cmd failed
A polled command failed because of timeouts or bus errors.
Disconnected command timeout for Target <id>.<lun>
A timeout occurred while target/lun was disconnected. This is usually a target f/w problem. For tagged queuing targets, <n> commands were outstanding when the timeout was detected.
Disconnected tagged cmds (<n>) timeout for Target <id>.<lun>
A timeout occurred while target/lun was disconnected. This is usually a target f/w problem. For tagged queuing targets, <n> commands were outstanding when the timeout was detected.
Connected command timeout for Target <id>.<lun>
This is usually a SCSI bus problem. Check cables and termination.
Target <id>.<lun> reverting to async. mode
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Target <id>.<lun> reducing sync. transfer rate
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Reverting to slow SCSI cable mode
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Reset SCSI bus failed
An attempt to reset the SCSI bus failed.
External SCSI bus reset
Another initiator reset the SCSI bus.

WARNINGS

The esp hardware does not support Wide SCSI mode. Only FAS-type esp's support fast SCSI (10 MB/sec).

NOTES

The esp driver exports properties indicating per target the negotiated transfer speed (target<n>-sync-speed) and whether tagged queuing has been enabled (target<n>-TQ). The sync-speed property value is the data transfer rate in KB/sec. The target-TQ property has no value. The existence of the property indicates that tagged queuing has been enabled. Refer to prtconf(1M) (verbose option) for viewing the esp properties.
dma, instance #3
  Register Specifications:
    Bus Type=0x2, Address=0x81000, Size=10
  esp, instance #3
     Driver software properties:
       name <target3-TQ> length <0> -- <no value>.
       name <target3-sync-speed> length <4>
         value <0x00002710>.
       name <scsi-options> length <4>
         value <0x000003f8>.
       name <scsi-watchdog-tick> length <4>
         value <0x0000000a>.
       name <scsi-tag-age-limit> length <4>
         value <0x00000008>.
       name <scsi-reset-delay> length <4>
         value <0x00000bb8>.
fas(7D)

NAME

fas - FAS SCSI Host Bus Adapter Driver

SYNOPSIS

fas@sbus-slot,0x8800000

DESCRIPTION

The fas Host Bus Adapter driver is a SCSA compliant nexus driver that supports the Qlogic FAS366 SCSI chip.
The fas driver supports the standard functions provided by the SCSA interface. The driver supports tagged and untagged queuing, wide and fast SCSI, almost unlimited transfer size (using a moving DVMA window approach), and auto request sense; but it does not support linked commands.

Driver Configuration

The fas driver can be configured by defining properties in fas.conf which override the global SCSI settings. Supported properties are: scsi-options, target<n>-scsi-options,
target<n>-sync-speed, target<n>-wide, target<n>-TQ, scsi-reset-delay, scsi-watchdog-
tick, scsi-tag-age-limit, scsi-initiator-id.
target<n>-scsi-options overrides the scsi-options property value for target<n>. <n> can vary from 0 to F. The supported scsi-options are: SCSI_OPTIONS_DR ,
SCSI_OPTIONS_SYNC ,SCSI_OPTIONS_TAG ,SCSI_OPTIONS_FAST,
SCSI_OPTIONS_WIDE .
scsi-watchdog-tick is the periodic interval where the fas driver goes through all current and disconnected commands searching for timeouts.
scsi-tag-age-limit is the number of times that the fas driver attempts to allocate a particular tag ID that is currently in use after going through all tag IDs in a circular fashion. After finding the same tag ID in use scsi-tag-age-limit times, no more commands will be submitted to this target until all outstanding commands complete or timeout.
Refer to scsi_hba_attach(9F) for details.

EXAMPLES

Create a file called /kernel/drv/fas.conf and add this line:
scsi-options=0x78;
This disables tagged queuing, fast SCSI, and Wide mode for all fas instances. The following example disables an option for one specific fas (refer to driver.conf(4) for more details):
name="fas" parent="/iommu@f,e0000000/sbus@f,e0001000"
   reg=3,0x8800000,0x10,3,0x8810000,0x40
   target1-scsi-options=0x58
   scsi-options=0x178 scsi-initiator-id=6;
Note that the default initiator ID in OBP is 7 and that the change to ID 6 will occur at attach time. It may be preferable to change the initiator ID in OBP.
The example above sets scsi-options for target 1 to 0x58 and all other targets on this SCSI bus to 0x178 .
The physical pathname of the parent can be determined using the /devices tree or following the link of the logical device name:
# ls -l /dev/rdsk/c1t3d0s0
lrwxrwxrwx 1 root other 78 Aug 28 16:05 /dev/rdsk/c1t3d0s0 ->
../../devices/iommu@f,e0000000/sbus@f,e0001000/SUNW,fas@3,8800000/sd@3,0:a,raw
Determine the register property values using the output from prtconf(1M) (with the -v option):
     SUNW,fas, instance #0
      ....
      Register Specifications:
        Bus Type=0x3, Address=0x8800000, Size=10
        Bus Type=0x3, Address=0x8810000, Size=40
scsi-options can also be specified per device type using the device inquiry sting. All the devices with the same inquiry string will have the same scsi-options set. This can be used to disable some scsi-options on all the devices of the same type.
     device-type-scsi-options-list=
             "TOSHIBA XM5701TASUN12XCD", "cd-scsi-options";

     cd-scsi-options = 0x0;
The above entry in /kernel/drv/fas.conf sets the scsi-options for all devices with inquiry string "TOSHIBA
XM5701TASUN12XCD" to "cd-options". To get the inquiry string run
probe-scsi or probe-scsi-all command at the ok prompt before booting the system.
To set scsi-options more specifically per target:
target1-scsi-options=0x78;
device-type-scsi-options-list =
    "SEAGATE ST32550W", "seagate-scsi-options" ;
seagate-scsi-options = 0x58;
scsi-options=0x3f8;
The above sets scsi-options for target 1 to 0x78 and for all other targets on this SCSI bus to 0x378 except for one specific disk type which will have scsi-options set to 0x58.
scsi-options specified per target ID have the highest precedence, followed by scsioptions per device type. Global fas scsi-options (effecting all instances) per bus have the lowest precedence.
The system needs to be rebooted before the specified scsi-options take effect.

Driver Capabilities

The target driver needs to set capabilities in the fas driver in order to enable some driver features. The target driver can query and modify these capabilities: synchronous, tagged-qing ,wide-xfer, auto-rqsense, qfull-retries, qfull-retry-interval. All other capabilities can only be queried.
By default, tagged-qing ,auto-rqsense, and wide-xfer capabilities are disabled, while disconnect, synchronous, and untagged-qing are enabled. These capabilities can only have binary values (0 or 1 ). The default values for qfull-retries and qfull-retry-interval are both 10 . The qfull-retries capability is a u_char (0 to 255 )while qfull-retry-interval is a u_short (0 to 65535 ).
The target driver needs to enable tagged-qing and wide-xfer explicitly. The untaggedqing capability is always enabled and its value cannot be modified, because fas can queue commands even when tagged-qing is disabled.
Whenever there is a conflict between the value of scsi-options and a capability, the value set in scsi-options prevails. Only whom != 0 is supported in the scsi_ifsetcap(9F) call.
Refer to scsi_ifsetcap(9F) and scsi_ifgetcap(9F) for details.

FILES

/kernel/drv/fas
ELF Kernel Module
/kernel/drv/fas.conf
Optional configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSparc SBus-based systems with FAS366 based SCSI port and SunSWIFT SBus SCSI adapter.

SEE ALSO

prtconf(1M), driver.conf(4), attributes(5), scsi_abort(9F), scsi_hba_attach(9F), scsi_ifgetcap(9F), scsi_ifsetcap(9F), scsi_reset(9F), scsi_sync_pkt(9F), scsi_transport(9F), scsi_device(9S), scsi_extended_sense(9S), scsi_inquiry(9S), scsi_pkt(9S)
Writing Device Drivers
OpenBoot Command Reference
ANSI Small Computer System Interface-2 (SCSI-2)
FAS366 Technical Manuals, QLogic Corp.

DIAGNOSTICS

The messages described below are some that may appear on the system console, as well as being logged.
The first five messages may be displayed while the fas driver is trying to attach; these messages mean that the fas driver was unable to attach. All of these messages are preceded by "fas%d", where "%d" is the instance number of the fas controller.
Device in slave-only slot
The SBus device has been placed in a slave-only slot and will not be accessible; move to non-slave-only SBus slot.
Device is using a hilevel intr
The device was configured with an interrupt level that cannot be used with this fas driver. Check the SBus device.
Cannot allocate soft state
Cannot alloc dma handle
Cannot alloc cmd area
Cannot create kmem_cache
Driver was unable to allocate memory for internal data structures.
Unable to map FAS366 registers
Driver was unable to map device registers; check for bad hardware. Driver did not attach to device; SCSI devices will be inaccessible.
Cannot add intr
Driver could not add it's interrupt service routine to the kernel.
Cannot map dma
Driver was unable to locate a dma controller. This is an auto-configuration error.
Cannot bind cmdarea
Driver was unable to bind the dma handle to an address.
Cannot create devctl minor node
Driver is unable to create a minor node for the controller.
Cannot attach
The driver was unable to attach; usually follows another warning that indicates why attach failed.
Disabled TQ since disconnects are disabled
        Tagged queuing was disabled because disconnects were disabled in scsi-options.
Bad clock frequency
Check for bad hardware.
Sync of pkt (<address>) failed
        Syncing a SCSI packet failed. Refer to scsi_sync_pkt(9F).
All tags in use!
The driver could not allocate another tag number. The target devices do not properly support tagged queuing.
Cannot alloc tag queue
The driver could not allocate space for tag queue.
Gross error in FAS366 status
The driver experienced severe SCSI bus problems. Check cables and terminator.
Spurious interrupt
The driver received an interrupt while the hardware was not interrupting.
Lost state in phasemanage
The driver is confused about the state of the SCSI bus.
Unrecoverable DMA error during selection
The DMA controller experienced host SBus problems. Check for bad hardware.
Bad sequence step (<step number>) in
The FAS366 hardware reported a bad sequence step. Check for bad hardware.
Undetermined selection failure
The selection of a target failed unexpectedly. Check for bad hardware.
Target <n>: failed reselection (bad reselect bytes)
A reconnect failed, target sent incorrect number of message bytes. Check for bad hardware.
Target <n>: failed reselection (bad identify message)
A reconnect failed, target didn't send identify message or it got corrupted. Check for bad hardware.
Target <n>: failed reselection (not in msgin phase)
Incorrect SCSI bus phase after reconnection. Check for bad hardware.
Target <n>: failed reselection (unexpected bus free)
Incorrect SCSI bus phase after reconnection. Check for bad hardware.
Target <n>: failed reselection (timeout on receiving tag msg)
A reconnect failed; target failed to send tag bytes. Check for bad hardware.
Target <n>: failed reselection (botched tag)
A reconnect failed; target failed to send tag bytes. Check for bad hardware.
Target <n>: failed reselection (invalid tag)
A reconnect failed; target sent incorrect tag bytes. Check for bad hardware.
Target <n>: failed reselection (Parity error in reconnect msg's)
A reconnect failed; parity error detected. Check for bad hardware.
Target <n>: failed reselection (no command)
A reconnect failed; target accepted abort or reset, but still tries to reconnect. Check for bad hardware.
Unexpected bus free
Target disconnected from the bus without notice. Check for bad hardware.
Target <n> didn't disconnect after sending <message>
The target unexpectedly did not disconnect after sending <message>.
Bad sequence step (0x?) in selection
The sequence step register shows an improper value. The target might be misbehaving.
Illegal dma boundary?
An attempt was made to cross a boundary that the driver could not handle.
Unwanted data xfer direction for Target <n>
The target went into an unexpected phase.
Spurious <name> phase from target <n>
The target went into an unexpected phase.
Unrecoverable DMA error on dma <send/receive>
There is a dma error while sening/receiving data. The host DMA controller is experiencing some problems.
SCSI bus DATA IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus MESSAGE IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus STATUS phase parity error
The driver detected parity errors on the SCSI bus.
Premature end of extended message
An extended SCSI bus message did not complete. Suspect a target f/w problem.
Premature end of input message
A multibyte input message was truncated. Suspect a target f/w problem.
Input message botch
The driver is confused about messages coming from the target.
Extended message <n> is too long
The extended message sent by the target is longer than expected.
<name> message <n> from Target <m> garbled
Target <m> sent message <name> of value <n> which the driver did not understand.
Target <n> rejects our message <name>
Target <n> rejected a message sent by the driver.
Rejecting message <name> from Target <n>
The driver rejected a message received from target <n>.
Cmd transmission error
The driver was unable to send out command bytes.
Target <n> refused message resend
The target did not accept a message resend.
MESSAGE OUT phase parity error
The driver detected parity errors on the SCSI bus.
Two-byte message <name> <value> rejected
The driver does not accept this two-byte message.
Unexpected selection attempt
An attempt was made to select this host adapter by another initiator.
Gross error in fas status <stat>
The fas chip has indicated a gross error like FIFO overflow.
Polled cmd failed (target busy)
A polled command failed because the target did not complete outstanding commands within a reasonable time.
Polled cmd failed
A polled command failed because of timeouts or bus errors.
Auto request sense failed
Driver is unable to get request sense from the target.
Disconnected command timeout for Target <id>.<lun>
A timeout occurred while target/lun was disconnected. This is usually a target f/w problem. For tagged queuing targets, <n> commands were outstanding when the timeout was detected.
Disconnected tagged cmds (<n>) timeout for Target <id>.<lun>
A timeout occurred while target/lun was disconnected. This is usually a target f/w problem. For tagged queuing targets, <n> commands were outstanding when the timeout was detected.
Connected command timeout for Target <id>.<lun>
This is usually a SCSI bus problem. Check cables and termination.
Target <id>.<lun> reverting to async. mode
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Target <id>.<lun> reducing sync. transfer rate
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Reverting to slow SCSI cable mode
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Target <id> reducing sync. transfer rate
Target <id> reverting to async. mode
Target <id> disabled wide SCSI mode
Due to problem's on the scsi bus the driver goes into more conservative mode of operation to avoid further problems.
Reset SCSI bus failed
An attempt to reset the SCSI bus failed.
External SCSI bus reset
Another initiator reset the SCSI bus.

WARNINGS

The fas hardware (FAS366) supports both Wide and fast SCSI mode, but fast20 is not supported. The maximum SCSI bandwidth is 20 MB/sec. Initiator mode block sequence (IBS) is not supported.

NOTES

The fas driver exports properties indicating per target the negotiated transfer speed (target<n>-sync-speed), whether wide bus is supported (target<n>-wide), scsi-options for that particular target (target<n>-scsi-options), and whether tagged queuing has been enabled (target<n>-TQ). The sync-speed property value is the data transfer rate in KB/sec. The target<n>-TQ and the target<n>-wide property have value 1 to indicate
that the corresponding capability is enabled, or 0 to indicate that the capability is disabled for that target. Refer to prtconf(1M) (verbose option) for viewing the fas properties.
SUNW,fas, instance #1
  Driver software properties:
    name <target3-TQ> length <4>
      value <0x00000001>.
    name <target3-wide> length <4>
      value <0x00000000>.
    name <target3-sync-speed> length <4>
      value <0x00002710>.
    name <target3-scsi-options> length <4>
      value <0x000003f8>.
    name <target0-TQ> length <4>
      value <0x00000001>.
    name <pm_norm_pwr> length <4>
      value <0x00000001>.
    name <pm_timestamp> length <4>
      value <0x30040346>.
    name <scsi-options> length <4>
      value <0x000003f8>.
    name <scsi-watchdog-tick> length <4>
      value <0x0000000a>.
    name <scsi-tag-age-limit> length <4>
      value <0x00000002>.
    name <scsi-reset-delay> length <4>
      value <0x00000bb8>.
  Register Specifications:
    Bus Type=0x3, Address=0x8800000, Size=10
    Bus Type=0x3, Address=0x8810000, Size=40
  Interrupt Specifications:
    Interrupt Priority=0x35 (ipl 5)
fbio(7I)

NAME

fbio - frame buffer control operations

DESCRIPTION

The frame buffers provided with this release support the same general interface that is defined by <sys/fbio.h>. Each responds to an FBIOGTYPE ioctl(2) request which returns information in a fbtype structure.
Each device has an FBTYPE which is used by higher-level software to determine how to perform graphics functions. Each device is used by opening it, doing an FBIOGTYPE ioctl( ) to see which frame buffer type is present, and thereby selecting the appropriate device-management routines.
FBIOGINFO returns information specific to the GS accelerator.
FBIOSVIDEO and FBIOGVIDEO are general-purpose ioctl( ) requests for controlling possible video features of frame buffers. These ioctl( ) requests either set or return the value of a flags integer. At this point, only the FBVIDEO_ON option is available, controlled by FBIOSVIDEO. FBIOGVIDEO returns the current video state.
The FBIOSATTR and FBIOGATTR ioctl( ) requests allow access to special features of newer frame buffers. They use the fbsattr and fbgattr structures.
Some color frame buffers support the FBIOPUTCMAP and FBIOGETCMAP ioctl( ) requests, which provide access to the colormap. They use the fbcmap structure.
Also, some framebuffers with multiple colormaps will either encode the colormap identifier in the high-order bits of the "index" field in the fbcmap structure, or use the FBIOPUTCMAPI and FBIOGETCMAPI ioctl( ) requests.
FBIOVERTICAL is used to wait for the start of the next vertical retrace period.
FBIOVRTOFFSET Returns the offset to a read-only vertical retrace page for those framebuffers that support it. This vertical retrace page may be mapped into user space with mmap(2). The first word of the vertical retrace page (type unsigned int) is a counter that is incremented every time there is a vertical retrace. The user process can use this counter in a variety of ways.
FBIOMONINFO returns a mon_info structure which contains information about the monitor attached to the framebuffer, if available.
FBIOSCURSOR, FBIOGCURSOR, FBIOSCURPOS and FBIOGCURPOS are used to control the hardware cursor for those framebuffers that have this feature. FBIOGCURMAX returns the maximum sized cursor supported by the framebuffer. Attempts to create a cursor larger than this will fail.
Finally FBIOSDEVINFO and FBIOGDEVINFO are used to transfer variable-length, devicespecific information into and out of framebuffers.

SEE ALSO

ioctl(2), mmap(2), bwtwo(7D), cgeight(7D), cgfour(7D), cgsix(7D), cgthree(7D), cgtwo(7D)

BUGS

The FBIOSATTR and FBIOGATTR ioctl( ) requests are only supported by frame buffers which emulate older frame buffer types. For example, cgfour(7D) frame buffers emulate bwtwo(7D) frame buffers. If a frame buffer is emulating another frame buffer, FBIOGTYPE returns the emulated type. To get the real type, use FBIOGATTR.
The FBIOGCURPOS ioctl was incorrectly defined in previous operating systems, and older code running in binary compatibility mode may get incorrect results.
fd(7D)

NAME

fd, fdc - drivers for floppy disks and floppy disk controllers

SYNOPSIS

SPARC

/dev/diskette0
/dev/rdiskette0

x86

/dev/diskette[0-1]
/dev/rdiskette[0-1]

DESCRIPTION

The fd driver provides the interfaces to the floppy disks using the Intel 82072 on sun4c systems and the Intel 82077 on sun4m systems.
The fd and fdc drivers provide the interfaces to floppy disks using the Intel 8272, Intel 82077, NEC 765, or compatible disk controllers on x86 based systems.
The default partitions for the floppy driver are:
a
All cylinders except the last
b
Only the last cylinder
c
Entire diskette
The fd driver autosenses the density of the diskette.
When the floppy is first opened the driver looks for a SunOS label in logical block 0 of the diskette. If attempts to read the SunOS label fail, the open will fail. If block 0 is read successfully but a SunOS label is not found, auto-sensed geometry and default partitioning are assumed.
The fd driver supports both block and raw interfaces. The block files access the diskette using the system's normal buffering mechanism and may be read and written without regard to physical diskette records. There is also a "raw" interface that provides for direct transmission between the diskette and the user's read or write buffer. A single read (2)or write(2) call usually results in one I/O operation; therefore raw I/O is considerably more efficient when many words are transmitted.

3.5" Diskettes

For 3.5" double-sided diskettes, the following densities are supported:

SPARC

  1. 7 Mbyte density

    80 cylinders, 21 sectors per track, 1.7 Mbyte capacity

high density
80 cylinders, 18 sectors per track, 1.44 Mbyte capacity
double density
80 cylinders, 9 sectors per track, 720 Kbyte capacity
medium density
77 cylinders, 8 sectors per track, 1.2 Mbyte capacity
(sun4m only)

x86

extended density
80 cylinders, 36 sectors per track, 2.88 Mbyte capacity
  1. 7 Mbyte density

    80 cylinders, 21 sectors per track, 1.7 Mbyte capacity

high density
80 cylinders, 18 sectors per track, 1.44 Mbyte capacity
double density
80 cylinders, 9 sectors per track, 760 Kbyte capacity

5.25" Diskettes

For 5.25" double-sided diskettes, the following densities are supported:

SPARC

  1. 25" diskettes are not supported.

x86

high density
80 cylinders, 15 sectors per track, 1.2 Mbyte capacity
double density
40 cylinders, 9 sectors per track, 360 Kbyte capacity
double density
40 cylinders, 8 sectors per track, 320 Kbyte capacity
quad density
80 cylinders, 9 sectors per track, 720 Kbyte capacity
double density
40 cylinders, 16 sectors per track (256 bytes per sector), 320
Kbyte capacity
double density
40 cylinders, 4 sectors per track (1024 bytes per sector), 320
Kbyte capacity

ERRORS

EBUSY
During opening, the partition has been opened for exclusive access and another process wants to open the partition. Once open, this error is returned if the floppy disk driver attempted to pass a command to the floppy disk controller when the controller was busy handling another command. In this case, the application should try the operation again.
EFAULT
An invalid address was specified in an ioctl command (see fdio(7I)).
EINVAL
The number of bytes read or written is not a multiple of the diskette's sector size. This error is also returned when an unsupported command is specified using the FDIOCMD ioctl command (see fdio(7I)).
EIO
During opening, the diskette does not have a label or there is no diskette in the drive. Once open, this error is returned if the requested I/O transfer could not be completed.
ENOSPC
An attempt was made to write past the end of the diskette.
ENOTTY
The floppy disk driver does not support the requested ioctl functions (see fdio(7I)).
ENXIO
The floppy disk device does not exist or the device is not ready.
EROFS
The floppy disk device is opened for write access and the diskette in the drive is write protected.

x86 Only

ENOSYS
The floppy disk device does not support the requested ioctl function ( FDEJECT).

x86 CONFIGURATION

The driver attempts to initialize itself using the information found in the configuration file, /platform/i86pc/kernel/drv/fd.conf.
name="fd" parent="fdc" unit=0;
name="fd" parent="fdc" unit=1;

FILES

SPARC

/platform/sun4c/kernel/drv/fd
driver module
/platform/sun4m/kernel/drv/fd
driver module
/platform/sun4u/kernel/drv/fd
driver module
/usr/include/sys/fdreg.h
structs and definitions for Intel 82072 and 82077 controllers
/usr/include/sys/fdvar.h
structs and definitions for floppy drivers
/dev/diskette
device file
/dev/diskette0
device file
/dev/rdiskette
raw device file
/dev/rdiskette0
raw device file
For ucb compatibility:
/dev/fd0[a-c]
block file
/dev/rfd0[a-c]
raw file
/vol/dev/diskette0
directory containing volume management character device
file
/vol/dev/rdiskette0
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy0
symbolic link to the entry in /vol/dev/rdiskette0

x86

/platform/i86pc/kernel/drv/fd
driver module
/platform/i86pc/kernel/drv/fd.conf
configuration file for floppy driver
/platform/i86pc/kernel/drv/fdc
floppy-controller driver module
/platform/i86pc/kernel/drv/fdc.conf
configuration file for the floppy-controller
/usr/include/sys/fdc.h
structs and definitions for x86 floppy devices
/usr/include/sys/fdmedia.h
structs and definitions for x86 floppy media
x86 First Drive:
/dev/diskette
device file
/dev/diskette0
device file
/dev/rdiskette
raw device file
/dev/rdiskette0
raw device file
For ucb compatibility:
/dev/fd0[a-c]
block file
/dev/rfd0[a-c]
raw file
/vol/dev/diskette0
directory containing volume management character device
file
/vol/dev/rdiskette0
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy0
symbolic link to the entry in /vol/dev/rdiskette0
x86 Second Drive:
/dev/diskette1
device file
/dev/rdiskette1
raw device file
For ucb compatibility:
/dev/fd1[a-c]
block file
/dev/rfd1[a-c]
raw file
/vol/dev/diskette1
directory containing volume management character device
file
/vol/dev/rdiskette1
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy1
symbolic link to the entry in /vol/dev/rdiskette1

SEE ALSO

fdformat(1), dd(1M), drvconfig(1M), vold(1M), read (2),write(2), driver.conf(4), dkio(7I), fdio(7I)

DIAGNOSTICS

fd<n>: <command name> failed (<sr1> <sr2> <sr3>)
The <command name> failed after several retries on drive <n>. The three hex values in parenthesis are the contents of status register 0, status register 1, and status register 2 of the Intel 8272, the Intel 82072, and the Intel 82077 Floppy Disk Controller on completion of the command as documented in the data sheet for that part. This error message is usually followed by one of the following, interpreting the bits of the status register:
fd <n>: not writable
fd<n>: crc error blk <block number>
        There was a data error on <block number>.
fd <n>: bad format
fd <n>: timeout
fd <n>: drive not ready
fd <n>: unformatted diskette or no diskette in drive
fd <n>: block <block number> is past the end! (nblk=<total number of
        blocks>)
The operation tried to access a block number that is greater than the total number of blocks.
fd <n>:
b_bcount 0x<op_size> not % 0x<sect_size>
The size of an operation is not a multiple of the sector size.
fd <n>: overrun/underrun
fd <n>: host bus error
        There was a hardware error on a system bus.

SPARC Only

Overrun/underrun errors occur when accessing a diskette while the system is heavily loaded. Decrease the load on the system and retry the diskette access.

NOTES

  1. 5" high density diskettes have 18 sectors per track and 5.25" high density diskettes have 15 sectors per track. They can cross a track (though not a cylinder) boundary without losing data, so when using dd(1M) to or from a diskette, you should specify bs=18k or multiples thereof for 3.5" diskettes, and bs=15k or multiples thereof for 5.25" diskettes.

The SPARC fd driver is not an unloadable module.
Under Solaris (Intel Platform Edition), the configuration of the floppy drives is specified in CMOS configuration memory. Use the BIOS setup program or an EISA or MicroChannel configuration program for the system to define the diskette size and density/capacity for each installed drive. Note that MS-DOS may operate the floppy drives correctly, even though the CMOS configuration may be in error. Solaris (Intel Platform Edition) relies on the CMOS configuration to be accurate.
fdc(7D)

NAME

fd, fdc - drivers for floppy disks and floppy disk controllers

SYNOPSIS

SPARC

/dev/diskette0
/dev/rdiskette0

x86

/dev/diskette[0-1]
/dev/rdiskette[0-1]

DESCRIPTION

The fd driver provides the interfaces to the floppy disks using the Intel 82072 on sun4c systems and the Intel 82077 on sun4m systems.
The fd and fdc drivers provide the interfaces to floppy disks using the Intel 8272, Intel 82077, NEC 765, or compatible disk controllers on x86 based systems.
The default partitions for the floppy driver are:
a
All cylinders except the last
b
Only the last cylinder
c
Entire diskette
The fd driver autosenses the density of the diskette.
When the floppy is first opened the driver looks for a SunOS label in logical block 0 of the diskette. If attempts to read the SunOS label fail, the open will fail. If block 0 is read successfully but a SunOS label is not found, auto-sensed geometry and default partitioning are assumed.
The fd driver supports both block and raw interfaces. The block files access the diskette using the system's normal buffering mechanism and may be read and written without regard to physical diskette records. There is also a "raw" interface that provides for direct transmission between the diskette and the user's read or write buffer. A single read (2)or write(2) call usually results in one I/O operation; therefore raw I/O is considerably more efficient when many words are transmitted.

3.5" Diskettes

For 3.5" double-sided diskettes, the following densities are supported:

SPARC

  1. 7 Mbyte density

    80 cylinders, 21 sectors per track, 1.7 Mbyte capacity

high density
80 cylinders, 18 sectors per track, 1.44 Mbyte capacity
double density
80 cylinders, 9 sectors per track, 720 Kbyte capacity
medium density
77 cylinders, 8 sectors per track, 1.2 Mbyte capacity
(sun4m only)

x86

extended density
80 cylinders, 36 sectors per track, 2.88 Mbyte capacity
  1. 7 Mbyte density

    80 cylinders, 21 sectors per track, 1.7 Mbyte capacity

high density
80 cylinders, 18 sectors per track, 1.44 Mbyte capacity
double density
80 cylinders, 9 sectors per track, 760 Kbyte capacity

5.25" Diskettes

For 5.25" double-sided diskettes, the following densities are supported:

SPARC

  1. 25" diskettes are not supported.

x86

high density
80 cylinders, 15 sectors per track, 1.2 Mbyte capacity
double density
40 cylinders, 9 sectors per track, 360 Kbyte capacity
double density
40 cylinders, 8 sectors per track, 320 Kbyte capacity
quad density
80 cylinders, 9 sectors per track, 720 Kbyte capacity
double density
40 cylinders, 16 sectors per track (256 bytes per sector), 320
Kbyte capacity
double density
40 cylinders, 4 sectors per track (1024 bytes per sector), 320
Kbyte capacity

ERRORS

EBUSY
During opening, the partition has been opened for exclusive access and another process wants to open the partition. Once open, this error is returned if the floppy disk driver attempted to pass a command to the floppy disk controller when the controller was busy handling another command. In this case, the application should try the operation again.
EFAULT
An invalid address was specified in an ioctl command (see fdio(7I)).
EINVAL
The number of bytes read or written is not a multiple of the diskette's sector size. This error is also returned when an unsupported command is specified using the FDIOCMD ioctl command (see fdio(7I)).
EIO
During opening, the diskette does not have a label or there is no diskette in the drive. Once open, this error is returned if the requested I/O transfer could not be completed.
ENOSPC
An attempt was made to write past the end of the diskette.
ENOTTY
The floppy disk driver does not support the requested ioctl functions (see fdio(7I)).
ENXIO
The floppy disk device does not exist or the device is not ready.
EROFS
The floppy disk device is opened for write access and the diskette in the drive is write protected.

x86 Only

ENOSYS
The floppy disk device does not support the requested ioctl function ( FDEJECT).

x86 CONFIGURATION

The driver attempts to initialize itself using the information found in the configuration file, /platform/i86pc/kernel/drv/fd.conf.
name="fd" parent="fdc" unit=0;
name="fd" parent="fdc" unit=1;

FILES

SPARC

/platform/sun4c/kernel/drv/fd
driver module
/platform/sun4m/kernel/drv/fd
driver module
/platform/sun4u/kernel/drv/fd
driver module
/usr/include/sys/fdreg.h
structs and definitions for Intel 82072 and 82077 controllers
/usr/include/sys/fdvar.h
structs and definitions for floppy drivers
/dev/diskette
device file
/dev/diskette0
device file
/dev/rdiskette
raw device file
/dev/rdiskette0
raw device file
For ucb compatibility:
/dev/fd0[a-c]
block file
/dev/rfd0[a-c]
raw file
/vol/dev/diskette0
directory containing volume management character device
file
/vol/dev/rdiskette0
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy0
symbolic link to the entry in /vol/dev/rdiskette0

x86

/platform/i86pc/kernel/drv/fd
driver module
/platform/i86pc/kernel/drv/fd.conf
configuration file for floppy driver
/platform/i86pc/kernel/drv/fdc
floppy-controller driver module
/platform/i86pc/kernel/drv/fdc.conf
configuration file for the floppy-controller
/usr/include/sys/fdc.h
structs and definitions for x86 floppy devices
/usr/include/sys/fdmedia.h
structs and definitions for x86 floppy media
x86 First Drive:
/dev/diskette
device file
/dev/diskette0
device file
/dev/rdiskette
raw device file
/dev/rdiskette0
raw device file
For ucb compatibility:
/dev/fd0[a-c]
block file
/dev/rfd0[a-c]
raw file
/vol/dev/diskette0
directory containing volume management character device
file
/vol/dev/rdiskette0
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy0
symbolic link to the entry in /vol/dev/rdiskette0
x86 Second Drive:
/dev/diskette1
device file
/dev/rdiskette1
raw device file
For ucb compatibility:
/dev/fd1[a-c]
block file
/dev/rfd1[a-c]
raw file
/vol/dev/diskette1
directory containing volume management character device
file
/vol/dev/rdiskette1
directory containing the volume management raw character
device file
/vol/dev/aliases/floppy1
symbolic link to the entry in /vol/dev/rdiskette1

SEE ALSO

fdformat(1), dd(1M), drvconfig(1M), vold(1M), read (2),write(2), driver.conf(4), dkio(7I), fdio(7I)

DIAGNOSTICS

fd<n>: <command name> failed (<sr1> <sr2> <sr3>)
The <command name> failed after several retries on drive <n>. The three hex values in parenthesis are the contents of status register 0, status register 1, and status register 2 of the Intel 8272, the Intel 82072, and the Intel 82077 Floppy Disk Controller on completion of the command as documented in the data sheet for that part. This error message is usually followed by one of the following, interpreting the bits of the status register:
fd <n>: not writable
fd<n>: crc error blk <block number>
        There was a data error on <block number>.
fd <n>: bad format
fd <n>: timeout
fd <n>: drive not ready
fd <n>: unformatted diskette or no diskette in drive
fd <n>: block <block number> is past the end! (nblk=<total number of
        blocks>)
The operation tried to access a block number that is greater than the total number of blocks.
fd <n>:
b_bcount 0x<op_size> not % 0x<sect_size>
The size of an operation is not a multiple of the sector size.
fd <n>: overrun/underrun
fd <n>: host bus error
        There was a hardware error on a system bus.

SPARC Only

Overrun/underrun errors occur when accessing a diskette while the system is heavily loaded. Decrease the load on the system and retry the diskette access.

NOTES

  1. 5" high density diskettes have 18 sectors per track and 5.25" high density diskettes have 15 sectors per track. They can cross a track (though not a cylinder) boundary without losing data, so when using dd(1M) to or from a diskette, you should specify bs=18k or multiples thereof for 3.5" diskettes, and bs=15k or multiples thereof for 5.25" diskettes.

The SPARC fd driver is not an unloadable module.
Under Solaris (Intel Platform Edition), the configuration of the floppy drives is specified in CMOS configuration memory. Use the BIOS setup program or an EISA or MicroChannel configuration program for the system to define the diskette size and density/capacity for each installed drive. Note that MS-DOS may operate the floppy drives correctly, even though the CMOS configuration may be in error. Solaris (Intel Platform Edition) relies on the CMOS configuration to be accurate.
fdio(7I)

NAME

fdio - floppy disk control operations

SYNOPSIS

#include <sys/fdio.h>

DESCRIPTION

The Solaris floppy driver supports a set of ioctl(2) requests for getting and setting the floppy drive characteristics. Basic to these ioctl( ) requests are the definitions in <sys/fdio.h>.

IOCTLS

The following ioctl( ) requests are available on the Solaris floppy driver.
FDDEFGEOCHAR
x86 based systems: This ioctl( ) forces the floppy driver to restore the diskette and drive characteristics and geometry, and partition information to default values based on the device configuration.
FDGETCHANGE
The argument is a pointer to an int. This ioctl( ) returns the status of the diskette-changed signal from the floppy interface. The following defines are provided for cohesion.
Note that for x86 based systems, use FDGC_DETECTED (which is available only on x86 based systems) instead of FDGC_HISTORY.
/*
        * Used by FDGETCHANGE, returned state of the sense disk change bit.
        * /
        #define FDGC_HISTORY             0x01    /* disk has changed since last call * /
        #define FDGC_CURRENT             0x02    /* current state of disk change * /
        #define FDGC_CURWPROT            0x10    /* current state of write protect * /
        #define FDGC_DETECTED            0x20    /* previous state of DISK CHANGE * /
FDIOGCHAR
The argument is a pointer to an fd_char structure (described below). This ioctl( ) gets the characteristics of the floppy diskette from the floppy controller.
FDIOSCHAR
The argument is a pointer to an fd_char structure (described below). This ioctl( ) sets the characteristics of the floppy diskette for the floppy controller. Typical values in the fd_char structure for a high density diskette:
field                  value
fdc_medium            0
fdc_transfer_rate     500
fdc_ncyl              80
fdc_nhead             2
fdc_sec_size          512
fdc_secptrack         18
fdc_steps             -1       { This field doesn't apply. }
/*
        * Floppy characteristics
        * /
        struct fd_char {
             u_char    fdc_medium;          /* equals 1 if medium type * /
             int       fdc_transfer_rate;   /* transfer rate * /
             int       fdc_ncyl;            /* number of cylinders * /
             int       fdc_nhead;           /* number of heads * /
             int       fdc_sec_size;        /* sector size * /
             int       fdc_secptrack;       /* sectors per track * /
             int       fdc_steps;           /* no. of steps per data track * /
        };
FDGETDRIVECHAR
The argument to this ioctl( ) is a pointer to an fd_drive structure (described below). This ioctl( ) gets the characteristics of the floppy drive from the floppy controller.
FDSETDRIVECHAR
                x86 based systems: The argument to this ioctl( ) is a pointer to an
                fd_drive structure (described below). This ioctl( ) sets the characteristics
                of the floppy drive for the floppy controller. Only fdd_steprate,
                fdd_headsettle, fdd_motoron, and fdd_motoroff are actually used by
the floppy disk driver.
/*
* Floppy Drive characteristics
* /
struct fd_drive {
     int  fdd_ejectable;       /* does the drive support eject? * /
     int  fdd_maxsearch;       /* size of per-unit search table * /
     int  fdd_writeprecomp; /* cyl to start write precompensation * /
     int  fdd_writereduce;     /* cyl to start recucing write current * /
     int  fdd_stepwidth;       /* width of step pulse in 1 us units * /
     int  fdd_steprate;        /* step rate in 100 us units * /
     int  fdd_headsettle;      /* delay, in 100 us units * /
     int  fdd_headload;        /* delay, in 100 us units * /
     int  fdd_headunload;      /* delay, in 100 us units * /
     int  fdd_motoron;         /* delay, in 100 ms units * /
     int  fdd_motoroff;        /* delay, in 100 ms units * /
     int  fdd_precomplevel; /* bit shift, in nano-secs * /
     int  fdd_pins;            /* defines meaning of pin 1, 2, 4 and 34 * /
     int  fdd_flags;            /* TRUE READY ,Starting Sector #, & Motor On * /
};
FDGETSEARCH Not available.
FDSETSEARCH Not available.
FDEJECT
SPARC: This ioctl( ) requests the floppy drive to eject the diskette.
FDIOCMD
The argument is a pointer to an fd_cmd structure (described below). This ioctl( ) allows access to the floppy diskette using the floppy device driver. Only the FDCMD_WRITE, FDCMD_READ, and
FDCMD_FORMAT_TR commands are currently available.
struct fd_cmd {
     u_short   fdc_cmd;        /* command to be executed * /
     int       fdc_flags;       /* execution flags (x86 only) * /
     daddr_t fdc_blkno;        /* disk address for command * /
     int       fdc_secnt;      /* sector count for command * /
     caddr_t   fdc_bufaddr;    /* user's buffer address * /
     u_int     fdc_buflen;      /* size of user's buffer * /
};
Please note that the fdc_buflen field is currently unused. The fdc_secnt field is used to calculate the transfer size, and the buffer is assumed to be large enough to accommodate the transfer.
                struct fd_cmd {
                /*
                 * Floppy commands
                 * /
                #define    FDCMD_WRITE                      1
                #define    FDCMD_READ                       2
                #define    FDCMD_SEEK                       3
                #define    FDCMD_REZERO                     4
                #define    FDCMD_FORMAT_UNIT                5
                #define    FDCMD_FORMAT_TRACK               6
                };
FDRAW
The argument is a pointer to an fd_raw structure (described below). This ioctl( ) allows direct control of the floppy drive using the floppy controller. Refer to the appropriate floppy-controller data sheet for full details on required command bytes and returned result bytes. The following commands are supported.
/*
* Floppy raw commands
* /
#define FDRAW_SPECIFY             0x03
#define FDRAW_READID              0x0a (x86 only)
#define FDRAW_SENSE_DRV           0x04
#define FDRAW_REZERO              0x07
#define FDRAW_SEEK                0x0f
#define FDRAW_SENSE_INT           0x08 (x86 only)
#define FDRAW_FORMAT              0x0d
#define FDRAW_READTRACK           0x02
#define FDRAW_WRCMD               0x05
#define FDRAW_RDCMD               0x06
#define FDRAW_WRITEDEL            0x09
#define FDRAW_READDEL             0x0c
Please note that when using FDRAW_SEEK or FDRAW_REZERO, the driver automatically issues a FDRAW_SENSE_INT command to clear the interrupt from the FDRAW_SEEK or the FDRAW_REZERO. The result bytes returned by these commands are the results from the
FDRAW_SENSE_INT command. Please see the floppy-controller data sheet for more details on FDRAW_SENSE_INT.
/*
* Used by FDRAW
* /
struct fd_raw {
     char      fdr_cmd[10];    /* user-supplied command bytes * /
     short     fdr_cnum;       /* number of command bytes * /
     char      fdr_result[10]; /* controller-supplied result bytes * /
     u_short   fdr_nbytes;     /* number to transfer if read/write command * /
     char      * fdr_addr;     /* where to transfer if read/write command * /
};

SEE ALSO

ioctl(2), dkio(7I), fd (7D),hdio(7I)
ffb(7D)

NAME

ffb - 24-bit UPA color frame buffer and graphics accelerator

DESCRIPTION

ffb is a 24-bit UPA-based color frame buffer and graphics accelerator which comes in two configurations.
The single buffered frame buffer consists of 32 video memory planes of 1280 . 1024 pixels, including 24-bit single-buffering and 8-bit X planes.
The double buffered frame buffer consists of 96 video memory planes of 1280 . 1024 pixels, including 24-bit double-buffering, 8-bit X planes, 28-bit Z-buffer planes and 4-bit Y planes. The driver supports the following frame buffer ioctls which are defined in fbio(7I).
FBIOPUTCMAP, FBIOGETCMAP, FBIOSVIDEO, FBIOGVIDEO,
FBIOVERTICAL, FBIOSCURSOR, FBIOGCURSOR, FBIOSCURPOS,
FBIOGCURPOS, FBIOGCURMAX, FBIO_WID_PUT, FBIO_WID_GET

FILES

/dev/fbs/ffb0
device special file

SEE ALSO

ffbconfig(1M), mmap(2), fbio(7I)
gld(7D)

NAME

gld - Generic LAN Driver

SYNOPSIS

#include <sys/stropts.h>
#include <sys/stream.h>
#include <sys/dlpi.h>
#include <sys/ethernet.h>
#include <sys/gld.h>

DESCRIPTION

gld is a multi-threaded, clonable Generic LAN Driver support module which resides in a loadable kernel module, /kernel/misc/gld. It implements most of the STREAMS functions and DLPI functionality required of a LAN driver. Several Solaris network drivers are implemented using GLD.
Any Solaris network driver implemented using GLD is divided into two distinct parts: a generic part that deals with STREAMS and DLPI interfaces, and a device-specific part that deals with the particular hardware device. The device-specific module indicates its dependency on the GLD module and registers itself with GLD from within the driver's attach(9E) function. After the driver has been successfully loaded, it is a fully DLPI-compliant driver. The device-specific part of the driver calls GLD functions when it receives data or needs some service from GLD. GLD makes indirect calls into the devicespecific driver through pointers provided to GLD by the device-specific driver when it registered itself with GLD.
DLPI is an implementation of a standard that defines the services provided by the data link layer. The data link interface is the boundary between the network and the data link layers of the OSI Reference Model. The network layer entity is the user of the services of the data link interface (DLS user). The data link layer entity is the provider of those services (DLS provider). The DLS user accesses the provider using open(9E) to establish a STREAM to the DLS provider. The STREAM acts as a communication channel between a DLS user and a DLS provider.

gld and Ethernet V2 and 802.3

Ethernet V2 service and 802.3 mode are provided by GLD. 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. A Service Access Point (SAP) is the point through which the user will communicate with the service provider. SAP values in the range [0-1500] are treated as equivalent and represent a desire by the user for 802.3 mode. If the value of the SAP field of the DL_BIND_REQ is within this range, GLD computes the length, not including initial M_PROTO message blocks, of all subsequent DL_UNITDATA_REQ messages and transmits 802.3 frames having this value in the MAC frame header type field. All frames received from the media having a type field in this range are assumed to be 802.3 frames and are routed up all open STREAMS that are bound to any SAP value within this range. If more than one STREAM is in 802.3 mode, the frame will be duplicated and routed up multiple STREAMS as DL_UNITDATA_IND messages.

gld and Style 1 and 2 Providers

GLD implements both Style 1 and Style 2 providers. The Style 1 provider assigns a physical point of attachment (PPA) based on the major/minor device that has been opened and bound. A PPA is the point at which a system attaches itself to a physical communication medium. All communication on that physical medium funnels through the PPA. The Style 2 provider requires the DLS user to explicitly identify the desired PPA using DL_ATTACH_REQ .open(9E) creates a STREAM between GLD and the device and DL_ATTACH_REQ ,then associates a particular PPA with that STREAM. Style 2 is denoted by a minor number of zero. If the minor number is not zero, it denotes the PPA number plus one. In both Style 1 and Style 2 opens, the device is cloned.
GLD implements a connectionless-mode service. Once the STREAM is initialized, connectionless data transfer can begin. Because there is no established connection, the DLS user must identify the destination of each data unit to be transferred.

Implemented DLPI Primitives

GLD implements the following DLPI primitives:
The DL_INFO_REQ primitive requests information about the DLPI STREAM. The message consists of one M_PCPROTO message block. GLD-based drivers return device-dependent values in the DL_INFO_ACK response to this request. However, all GLD-based drivers return the following values:
The version is DL_VERSION_2 .
The service mode is DL_CLDLS .
The provider style is DL_STYLE1 or DL_STYLE2 .
No optional Quality Of Service (QOS) support is present, so the QOS fields are zero.
The DL_ATTACH_REQ primitive is called to associate a PPA with a STREAM. This request is needed for Style 2 DLS providers to identify the physical medium over which the communication will transpire. This request may not be issued when using the driver in Style 1 mode. Upon completion, the state changes from DL_UNATTACHED to DL_UNBOUND . The message consists of one M_PROTO message block.
The DL_DETACH_REQ primitive requests detach from the physical point of attachment from a STREAM.
The DL_BIND and DL_UNBIND primitives bind and unbind a DLSAP to the STREAM. The PPA associated with each STREAM will be initialized upon completion of the processing of the DL_BIND_REQ .Multiple STREAMS may be bound to the same SAP; each STREAM receives a copy of any packets received for that SAP.
The DL_ENABMULTI_REQ and DL_DISABMULTI_REQ primitives enable and disable reception of individual multicast group addresses. A set of multicast addresses may be iteratively created and modified on a per-STREAM basis using these primitives. These primitives are accepted by the driver in any state following DL_ATTACHED .
The DL_PROMISCON_REQ and DL_PROMISCOFF_REQ primitives enables and disables promiscuous mode on a per-STREAM basis, either at a physical level or at the SAP level. The DL Provider will route all received messages on the media to the DLS User until either a DL_DETACH_REQ or a DL_PROMISCOFF_REQ is received or the STREAM is
closed.
The DL_UNITDATA_REQ primitive is used to send data in a connectionless transfer. Because this is an unacknowledged service, there is no guarantee of delivery. The message consists of one M_PROTO message block followed by one or more M_DATA blocks containing at least one byte of data.
The DL_PHYS_ADDR_REQ primitive returns the 6-octet Ethernet address currently associated (attached) to the STREAM in the DL_PHYS_ADDR_ACK primitive. When using style 2, this primitive is only valid following a successful DL_ATTACH_REQ .
The DL_SET_PHYS_ADDR_REQ primitive changes the 6-octet Ethernet address currently associated (attached) to this STREAM. The credentials of the process which originally opened the STREAM must be superuser or an EPERM error is returned in the DL_ERROR_ACK .This primitive is destructive in that it affects all other current and future STREAMS attached to this device. An M_ERROR is sent up all other STREAMS attached to this device when this primitive on this STREAM is successful. Once changed, all STREAMS subsequently opened and attached to this device will obtain this new physical address. The new physical address will remain in effect until this primitive is used to change the physical address again or the system is rebooted, whichever occurs first.
The DL_UNITDATA_IND type is used when a packet is received and is to be passed upstream. The packet is put into an M_PROTO message with the primitive set to DL_UNITDATA_IND .
The interface between GLD and GLD-based drivers is an internal interface not currently published for external use.

FILES

/kernel/misc/gld
loadable kernel module

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPEATTRIBUTE VALUE
Architecturex86

SEE ALSO

attributes(5), dlpi(7P), attach(9E), open(9E)

WARNINGS

Contrary to the DLPI specification, GLD returns the device's correct address length and broadcast address in DL_INFO_ACK even before the device has been attached.
glm(7D)

NAME

glm - GLM SCSI Host Bus Adapter Driver

SYNOPSIS

glm@bus-type

DESCRIPTION

The glm Host Bus Adapter driver is a SCSA compliant nexus driver that supports the Symbios 53c875 SCSI chip.
It supports the standard functions provided by the SCSA interface, that is, it supports untagged queuing, wide/fast/Ultra SCSI, and auto request sense; but does not support linked commands.

Driver Configuration

Configure the glm driver by defining properties in glm.conf. These properties override the global SCSI settings. glm supports these properties which can be modified by the user: scsi-options, target<n>-scsi-options, scsi-reset-delay, scsi-watchdog-tick, and
scsi-initiator-id.
target<n>-scsi-options overrides the scsi-options property value for target<n>. <n> can vary from hex 0 to F. glm supports these scsi-options: SCSI_OPTIONS_DR , SCSI_OPTIONS_SYNC ,SCSI_OPTIONS_FAST, SCSI_OPTIONS_WIDE ,and SCSI_OPTIONS_FAST20.
During the periodic interval scsi-watchdog-tick, glm searches through all current and disconnected commands for timeouts.

EXAMPLES

Create a file called /kernel/drv/glm.conf and add the following line:
scsi-options=0x78;
This disables fast/Ultra SCSI and wide mode for all glm instances.
To set scsi-options more specifically per target:
target1-scsi-options=0x78;
device-type-scsi-options-list =
        "SEAGATE ST32550W", "seagate-scsi-options" ;
seagate-scsi-options = 0x58;
scsi-options=0x3f8;
The above sets scsi-options for target 1 to 0x78 and for all other targets on this SCSI bus to 0x378 except for one specific disk type which will have scsi-options set to 0x58.
scsi-options specified per target ID have the highest precedence, followed by scsioptions per device type. Global scsi-options (for all glm instances) per bus have the lowest precedence.
The system needs to be rebooted before the specified scsi-options take effect.

Driver Capabilities

The target driver needs to set capabilities in the glm driver in order to enable some driver features. The target driver can query and modify these capabilities: synchronous, widexfer, auto-rqsense, All other capabilities can only be queried.
By default, auto-rqsense, and wide-xfer capabilities are disabled, while disconnect, synchronous, and untagged-qing are enabled. These capabilities can only have binary values (0 or 1 ). The target driver needs to enable wide-xfer explicitly. The untaggedqing capability is always enabled and its value cannot be modified.
Whenever there is a conflict between the value of scsi-options and a capability, the value set in scsi-options prevails. Only whom != 0 is supported in the scsi_ifsetcap(9F) call.
Refer to scsi_ifsetcap(9F) and scsi_ifgetcap(9F) for details.

FILES

/kernel/drv/glm
ELF Kernel Module
/kernel/drv/glm.conf
Optional configuration file

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE
ATTRIBUTE VALUE
ArchitectureLimited to PCI-based systems with Symbios 53c875 SCSI I/O processors.

SEE ALSO

prtconf(1M), driver.conf(4), attributes(5), scsi_abort(9F), scsi_hba_attach(9F), scsi_ifgetcap(9F), scsi_ifsetcap(9F), scsi_reset(9F), scsi_sync_pkt(9F), scsi_transport(9F), scsi_device(9S), scsi_extended_sense(9S), scsi_inquiry(9S), scsi_pkt(9S),
Writing Device Drivers
ANSI Small Computer System Interface-2 (SCSI-2),
Symbios Logic Inc., SYM53c875 PCI-SCSI I/O Processor With Fast-20

DIAGNOSTICS

The messages described below are some that may appear on the system console, as well as being logged.
Device is using a hilevel intr
The device was configured with an interrupt level that cannot be used with this glm driver. Check the PCI device.
map setup failed
Driver was unable to map device registers; check for bad hardware. Driver did not attach to device; SCSI devices will be inaccessible.
glm_scrip_alloc failed
The driver was unable to load the SCRIPTS for the scsi processor, check for bad hardware. Driver did not attach to device; SCSI devices will be inaccessible.
cannot map configuration space.
The driver was unable to map in the configuration registers. Check for bad hardware. SCSI devices will be inaccessible.
attach failed
The driver was unable to attach; usually preceeded by another warning that indicates why attach failed. These can be considered hardware failure.
SCSI bus DATA IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus MESSAGE IN phase parity error
The driver detected parity errors on the SCSI bus.
SCSI bus STATUS phase parity error
The driver detected parity errors on the SCSI bus.
Unexpected bus free
Target disconnected from the bus without notice. Check for bad hardware.
Disconnected command timeout for Target <id>.<lun>
A timeout occurred while target/lun was disconnected. This is usually a target f/w problem. For tagged queuing targets, <n> commands were outstanding when the timeout was detected.
Connected command timeout for Target <id>.<lun>
This is usually a SCSI bus problem. Check cables and termination.
Target <id> reducing sync. transfer rate
A data transfer hang was detected. The driver attempts to eliminate this problem by reducing the data transfer rate.
Target <id> reverting to async. mode
A second data transfer hang was detected for this target. The driver attempts to eliminate this problem by reducing the data transfer rate.
Target <id> disabled wide SCSI mode
A second data phase hang was detected for this target. The driver attempts to eliminate this problem by disabling wide SCSI mode.
auto request sense failed
An attempt to start an auto request pkt failed. Another auto request pkt may already be in transport.
invalid reselection (<id>.<lun>)
A reselection failed; target accepted abort or reset, but still tries to reconnect. Check for bad hardware.
invalid intcode
The SCRIPTS processor generated an invalid SCRIPTS interrupt. Check for bad hardware.

NOTES

The glm hardware (53C875) supports wide, fast and Ultra SCSI mode. The maximum SCSI bandwidth is 40 MB/sec.
The glm driver exports properties indicating per target the negotiated transfer speed (target<n>-sync-speed), whether wide bus is supported (target<n>-wide), for that particular target (target<n>-scsi-options), and whether tagged queuing has been enabled (target<n>-TQ). The sync-speed property value is the data transfer rate in KB/sec. The
target<n>-TQ and the target<n>-wide property have value 1 to indicate that the corresponding capability is enabled, or 0 to indicate that the capability is disabled for that target. Refer to prtconf(1M) (verbose option) for viewing the glm properties.
scsi, instance #0
  Driver properties:
    name <target6-TQ> length <4>
      value <0x00000000>.
    name <target6-wide> length <4>
      value <0x00000000>.
    name <target6-sync-speed> length <4>
      value <0x00002710>.
    name <target1-TQ> length <4>
      value <0x00000000>.
    name <target1-wide> length <4>
      value <0x00000001>.
    name <target1-sync-speed> length <4>
      value <0x00009c40>.
    name <target0-TQ> length <4>
      value <0x00000000>.
    name <target0-wide> length <4>
      value <0x00000001>.
    name <target0-sync-speed> length <4>
      value <0x00009c40>.
    name <scsi-options> length <4>
      value <0x000007f8>.
    name <scsi-watchdog-tick> length <4>
      value <0x0000000a>.
    name <scsi-tag-age-limit> length <4>
      value <0x00000002>.
    name <scsi-reset-delay> length <4>
      value <0x00000bb8>.
    name <latency-timer> length <4>
      value <0x00000088>.
    name <cache-line-size> length <4>
      value <0x00000010>.
hdio(7I)

NAME

hdio - SMD and IPI disk control operations

SYNOPSIS

#include <sys/hdio.h>

DESCRIPTION

The SMD and IPI disk drivers supplied with this release support a set of ioctl(2) requests for diagnostics and bad sector information. Basic to these ioctl( ) requests are the definitions in <sys/hdio.h>.

IOCTLS

HDKIOCGTYPE The argument is a pointer to a hdk_type structure (described below).
This ioctl( ) gets specific information from the hard disk.
HDKIOCSTYPE The argument is a pointer to a hdk_type structure (described below).
This ioctl( ) sets specific information about the hard disk.
/*
                 * Used for drive info
                 * /
                struct hdk_type {
                      u_short    hdkt_hsect;         /* hard sector count (read only) * /
                      u_short    hdkt_promrev;       /* prom revision (read only) * /
                      u_char     hdkt_drtype;        /* drive type (ctlr specific) * /
                      u_char     hdkt_drstat;        /* drive status (ctlr specific, ro) * /
                };
HDKIOCGBAD The argument is a pointer to a hdk_badmap structure (described
below). This ioctl( ) is used to get the bad sector map from the disk.
HDKIOCSBAD
The argument is a pointer to a hdk_badmap structure (described below). This ioctl( ) is used to set the bad sector map on the disk.
/*
                 * Used for bad sector map
                 * /
                struct hdk_badmap {
                      caddr_t    hdkb_bufaddr;       /* address of user's map buffer * /
                };
HDKIOCGDIAG
The argument is a pointer to a hdk_diag structure (described below). This ioctl( ) gets the most recent command that failed along with the sector and error number from the hard disk.
/*
* Used for disk diagnostics
* /
struct hdk_diag {
     u_short    hdkd_errcmd;        /* most recent command in error * /
     daddr_t    hdkd_errsect;       /* most recent sector in error * /
     u_char     hdkd_errno;         /* most recent error number * /
     u_char     hdkd_severe;        /* severity of most recent error * /
};

SEE ALSO

ioctl(2), dkio(7I), ipi(7D), xd(7D), xy(7D)
hme(7D)

NAME

hme - SUNW,hme Fast-Ethernet device driver

SYNOPSIS

/dev/hme

DESCRIPTION

The SUNW,hme Fast-Ethernet driver is a multi-threaded, loadable, clonable, STREAMS hardware driver supporting the connectionless Data Link Provider Interface, dlpi(7P), over a SUNW,hme Fast-Ethernet controller. The motherboard and add-in SBus SUNW,hme controllers of several varieties are supported. Multiple SUNW,hme controllers installed within the system are supported by the driver. The hme driver provides basic support for the SUNW,hme hardware. It is used to handle the SUNW,hme device. Functions include chip initialization, frame transit and receive, multicast and promiscuous support, and error recovery and reporting. SUNW,hme The SUNW,hme device provides 100Base-TX networking interfaces using SUN's FEPS ASIC and an Internal Transceiver. The FEPS ASIC provides the Sbus interface and MAC functions and the Physical layer functions are provided by the Internal Transceiver which connects to a RJ-45 connector. In addition to the RJ-45 connector, an MII (Media Independent Interface) connector is also provided on all SUNW,hme devices except the SunSwith SBus adapter board. The MII interface is used to connect to an External Transceiver which may use any physical media (copper or fiber) specified in the 100Base-TX standard. When an External Transceiver is connected to the MII, the driver selects the External Transceiver and disables the Internal Transceiver.
The 100Base-TX standard specifies an "auto-negotiation" protocol to automatically select the mode and speed of operation. The Internal transceiver is capable of doing "autonegotiation" with the remote-end of the link (Link Partner) and receives the capabilities of the remote end. It selects the Highest Common Denominator mode of operation based on the priorities. It also supports forced-mode of operation where the driver can select the mode of operation.

APPLICATION PROGRAMMING

The cloning character-special device /dev/hme is used to access all SUNW,hme controllers installed within the system.

INTERFACE

hme and DLPI

The hme driver is a "style 2" Data Link Service provider. All M_PROTO and M_PCPROTO type messages are interpreted as DLPI primitives. Valid DLPI primitives are defined in <sys/dlpi.h>. Refer to dlpi(7P) for more information. An explicit DL_ATTACH_REQ message by the user is required to associate the opened stream with a particular device (ppa). The ppa ID is interpreted as an unsigned long data type and indicates the corresponding device instance (unit) number. An error (DL_ERROR_ACK )is returned by the driver if the ppa field value does not correspond to a valid device instance number for this system. The device is initialized on first attach and de-initialized (stopped) at last detach.
The values returned by the driver in the DL_INFO_ACK primitive in response to the DL_INFO_REQ from the user are as follows:
The maximum SDU is 1500 (ETHERMTU - defined in <sys/ethernet.h> ). The minimum SDU is 0 .
The dlsap address length is 8.
The MAC type is DL_ETHER .
The sap length values is -2 meaning the physical address component is followed immediately by a 2 byte sap component within the DLSAP address. The service mode is DL_CLDLS .
No optional quality of service (QOS) support is included at present so the QOS fields are 0 .
The provider style is DL_STYLE2 .
The version is DL_VERSION_2 .
The broadcast address value is Ethernet/IEEE broadcast address (0xFFFFFF).
Once in the DL_ATTACHED state, the user must send a DL_BIND_REQ to associate a particular SAP (Service Access Pointer) with the stream. The hme driver interprets the sap field within the DL_BIND_REQ as an Ethernet "type" therefore valid values for the sap field are in the [0 -0xFFFF] range. Only one Ethernet type can be bound to the stream at any time.
If the user selects a sap with a value of 0 ,the receiver will be in "802.3 mode". All frames received from the media having a "type" field in the range [0 -1500 ]are assumed to be 802.3 frames and are routed up all open Streams which are bound to sap value 0 . If more than one Stream is in "802.3 mode" then the frame will be duplicated and routed up multiple Streams as DL_UNITDATA_IND messages.
In transmission, the driver checks the sap field of the DL_BIND_REQ if the sap value is 0 , and if the destination type field is in the range [0 -1500 ]. If either is true, the driver computes the length of the message, not including initial M_PROTO mblk (message block), of all subsequent DL_UNITDATA_REQ messages and transmits 802.3 frames that have this value in the MAC frame header length field.
The hme driver DLSAP address format consists of the 6 byte physical (Ethernet) address component followed immediately by the 2 byte sap (type) component producing an 8 byte DLSAP address. Applications should not hardcode to this particular implementation-specific DLSAP address format but use information returned in the DL_INFO_ACK primitive to compose and decompose DLSAP addresses. The sap length, full DLSAP length, and sap/physical ordering are included within the DL_INFO_ACK. The physical address length can be computed by subtracting the sap length from the full DLSAP address length or by issuing the DL_PHYS_ADDR_REQ to obtain the current physical address associated with the stream.
Once in the DL_BOUND state, the user may transmit frames on the Ethernet by sending DL_UNITDATA_REQ messages to the hme driver. The hme driver will route received Ethernet frames up all those open and bound streams having a sap which matches the Ethernet type as DL_UNITDATA_IND messages. Received Ethernet frames are duplicated and routed up multiple open streams if necessary. The DLSAP address contained within the DL_UNITDATA_REQ and DL_UNITDATA_IND messages consists of both the sap (type) and physical (Ethernet) components.
In addition to the mandatory connectionless DLPI message set the driver additionally supports the following primitives.

hme Primitives

The DL_ENABMULTI_REQ and DL_DISABMULTI_REQ primitives enable/disable reception of individual multicast group addresses. A set of multicast addresses may be iteratively created and modified on a per-stream basis using these primitives. These primitives are accepted by the driver in any state following DL_ATTACHED .
The DL_PROMISCON_REQ and DL_PROMISCOFF_REQ primitives with the DL_PROMISC_PHYS flag set in the dl_level field enables/disables reception of all ("promiscuous mode") frames on the media including frames generated by the local host. When used with the DL_PROMISC_SAP flag set this enables/disables reception of all sap (Ethernet type) values. When used with the DL_PROMISC_MULTI flag set this enables/disables reception of all multicast group addresses. The effect of each is always on a per-stream basis and independent of the other sap and physical level configurations on this stream or other streams.
The DL_PHYS_ADDR_REQ primitive returns the 6 octet Ethernet address currently associated (attached) to the stream in the DL_PHYS_ADDR_ACK primitive. This primitive is valid only in states following a successful DL_ATTACH_REQ .
The DL_SET_PHYS_ADDR_REQ primitive changes the 6 octet Ethernet address currently associated (attached) to this stream. The credentials of the process which originally opened this stream must be superuser. Otherwise EPERM is returned in the DL_ERROR_ACK .This primitive is destructive in that it affects all other current and future streams attached to this device. An M_ERROR is sent up all other streams attached to this device when this primitive is successful on this stream. Once changed, all streams subsequently opened and attached to this device will obtain this new physical address. Once changed, the physical address will remain until this primitive is used to change the physical address again or the system is rebooted, whichever comes first.

hme DRIVER

By default, the hme driver performs "auto-negotiation" to select the mode and speed of the link, when the Internal Transceiver is used.
When an External Transceiver is connected to the MII interface, the driver selects the External Transceiver for networking operations. If the External Transceiver supports "auto-negotiation", the driver uses the auto-negotiation procedure to select the link speed and mode. If the External Transceiver does not support auto-negotiation, it will select the highest priority mode supported by the transceiver.
The link can be in one of the 4 following modes:
100 Mbps, full-duplex
100 Mbps, half-duplex
10 Mbps, full-duplex
10 Mbps, half-duplex
These speeds and modes are described in the 100Base-TX standard.
The auto-negotiation protocol automatically selects:
Operation mode (half-duplex or full-duplex)
Speed (100 Mbps or 10 Mbps)
The auto -negotiation protocol does the following:
Gets all the modes of operation supported by the Link Partner
<