Changes in the C language and its related tools are among the most obvious differences between the SunOS release 4.x and the Solaris 2.6 operating environments. These changes affect all developers to varying degrees. The operating system kernel and its interfaces have also changed significantly since the SunOS release 4.xsoftware. This part of the guide describes these differences, points out similarities between releases, provides information you need to port existing software, or to write new software for the Solaris 2.6 operating environment, and explains the implications for your programming environment.
This chapter discusses the changes to compilers, linkers, and debuggers.
The single most significant change for developers migrating from the SunOS release 4.x to the Solaris 2.6 operating environment is the unbundling of the C compiler. One of the factors that allowed the compiler to be unbundled is the dynamic kernel. The compiler is no longer required to reconfigure the kernel as devices are now automatically loaded by the kernel as needed.
An ANSI C compiler is available with unbundled Sun WorkShop(TM). This compiler produces executables in executable and linking format (ELF), the native object format of Solaris 2.6 executables. lint and the lint libraries are also unbundled.
Source Compatibility Guide describes the differences between the C language as implemented by the SunOS release 4.x C compiler (Sun C) and as described by the ANSI Programming Language C document (ANSI C). These differences should be addressed when porting source written for the Sun C compiler to an ANSI C conforming compiler.
Table 15-1 compares the SunOS release 4.x Sun C and ANSI C compilers to the Solaris 2.6 Sun WorkShop(TM) C++ 4.2. It is provided for your information, and is not intended to describe the range of operations available in default Solaris 2.6 software.
Table 15-1 presents information based on the publicly available copies of the American National Standard for Information Systems - Programming Language XX3.159-1989, approved December 14, 1989.
Please note the following:
A "yes" in any column indicates that the option is supported by that compiler.
If the option has changed, the new option is listed.
A "no" in any column means the option is not supported by that driver
A "+" in the Sun WorkShop(TM) C++ 4.2 Solaris 2.6 column indicates an option required by SVID specifications.
Option or Flag |
Sun C |
ANSI C |
Sun WorkShop(TM) C++ 4.2 |
Description |
---|---|---|---|---|
-A symbol |
No |
Yes |
Yes |
cpp predicate assertion |
-a |
Yes |
Yes |
-xa |
Counts # basic block executions |
-align |
Yes |
Yes |
No |
Page aligns (ld) |
-assertx |
Yes |
Yes |
-z |
Specifies link-time assertion |
-BX |
Yes |
Yes |
Yes |
Specifies binding type (only for libraries in SunOS release 5.6) |
-bnzero |
Yes |
Yes |
No |
Generates nonzero AR |
-C |
Yes |
Yes |
No |
cpp comments left in |
-c |
Yes |
Yes |
+Yes |
Produces .o file |
-cg87 |
Yes |
Yes |
No |
Sets fp option to -cg87 |
-cg89 |
Yes |
Yes |
Yes |
Sets fp option to -cg89 |
-dryrun |
Yes |
Yes |
Yes |
Shows commands constructed by driver |
-Dx |
Yes |
Yes |
+Yes |
Defines cpp symbol x |
-d |
Yes |
Yes |
No |
Forces definition of common (ld) |
-dalign |
Yes |
Yes |
Yes |
Assumes doubles are double-word aligned |
-dl |
Yes |
Yes |
No |
Generates long data segment refs |
-d[y|n] | -BX | -BX |
Yes |
Dynamic linking [yes|no] |
-E |
Yes |
Yes |
+Yes |
Runs source through cpp |
-e |
No |
No |
No |
Entry point for ld |
-F |
-O* |
-O* |
+No |
Optimization directives |
-f |
No |
No |
No |
Floating-point support |
-fast |
Yes |
Yes |
Yes |
Options for best performance |
-fsingle |
Yes |
No |
No |
Floats are single precision |
-fsingle2 |
Yes |
No |
No |
Passes float (as float not double) |
-fnonstd |
Yes |
Yes |
Yes |
Non-standard float option |
-fstore |
Yes |
No |
Yes |
Forces writes on store |
-G |
No |
No |
Yes |
Creates shared library, not available with the -dn option |
-g |
Yes |
Yes |
+Yes |
Generates info for dbx |
-go |
Yes |
No |
No |
Generates info for adb |
-H |
Yes |
Yes |
Yes |
Prints paths of included files |
-h name |
No |
No |
Yes |
Uses name as internal identifier; soname passed to linker |
-help |
Yes |
Yes |
-flags |
Lists options |
-Ix |
Yes |
Yes |
+Yes |
Adds x to include path |
-J |
sun3 |
No |
No |
Generates long offset for switch|case |
-KPIC |
-PIC |
-PIC |
Yes |
Position independent code |
-Kpic |
-pic |
-pic |
Yes |
PIC with short offsets |
-Kminabi |
No |
No |
No |
ABI compliant code |
-libmil |
Yes |
Yes |
-xlibmil |
Passes libm.il as part of -fast |
-lx |
Yes |
Yes |
Yes |
Reads object library (for ld) |
-Lx |
Yes |
Yes |
Yes |
Adds x to ld library path |
-M |
Yes |
Yes |
No |
Collects dependencies |
-M mapfile |
Yes |
No |
No |
Passes mapfile to the linker |
-misalign |
Yes |
Yes |
Yes |
Handles misaligned Sun-4 data |
-N |
Yes |
No |
No |
Does not make shared |
-n |
Yes |
No |
No |
Makes shared |
-native |
Yes |
Yes |
Yes |
Uses appropriate -cg option |
-noc2 |
Yes |
Yes |
No |
Doesn't do peephole optimization |
-nolibmil |
Yes |
Yes |
-xnolibmil |
Doesn't pass libm.il with -fast |
-o file |
Yes |
Yes |
+Yes |
Sets name of output file |
-O[1,2,3,4] |
Yes |
Yes |
-x0[1,2,3,4] |
Generates optimized code |
-O |
Yes |
Yes |
+Yes |
Generates optimized code |
-P |
Yes |
Yes |
+Yes |
Runs source through cpp, output to .i |
-PIC |
Yes |
No |
-KPIC |
Generates pic code with long offset |
-p |
Yes |
Yes |
+Yes |
Collects data for prof |
-pg |
Yes |
Yes |
-xpg |
Collects data for gprof |
-pic |
Yes |
Yes |
-Kpic |
pic code with short offset |
-pipe |
Yes |
No |
No |
Uses pipes instead of temp files |
-purecross |
Yes |
No |
No |
Doesn't have slash in VROOT |
-Qdir x |
Yes |
Yes |
-Y* |
Looks for compiler passes in x |
-Qpath x |
Yes |
Yes |
-Y* |
Same as -Qdir |
-Qn |
No |
No |
Yes |
Doesn't add version stamp info |
-Qy |
No |
No |
Yes |
Adds version stamp info |
-qdir x |
Yes |
Yes |
No |
Looks for compiler passes in x |
-ql |
No |
No |
No |
Collects data for lprof |
-qp |
-p |
-p |
-p |
Collects data for prof |
-qpath x |
Yes |
Yes |
No |
Same as -Qdir |
-Qoption cpp x |
Yes |
Yes |
Yes |
Passes option x on to program cpp |
-Qoption iropt x |
Yes |
Yes |
Yes |
Passes option x on to program iropt |
-Qoption cg x |
Yes |
Yes |
Yes |
Passes option x on to program cg |
-Qoption inline x |
Yes |
Yes |
No |
Passes option x on to program inline |
-Qoption as x |
Yes |
Yes |
No |
Passes option x on to program as |
-Qoption asS x |
Yes |
Yes |
No |
Passes option x on to program asS |
-Qoption ld x |
Yes |
Yes |
Yes |
Passes option x on to program ld |
-qoption cpp x |
Yes |
Yes |
No |
Passes option x on to program cpp |
-qoption ccom x |
Yes |
Yes |
No |
Passes option x on to program ccom |
-qoption lintl x |
Yes |
Yes |
No |
Passes option x on to program lint1 |
-qoption iropt x |
Yes |
Yes |
Yes |
Passes option x on to program iropt |
-qoption cg x |
Yes |
Yes |
Yes |
Passes option x on to program cg |
-qoption inline x |
Yes |
Yes |
No |
Passes option x on to program inline |
-qoption cat x |
Yes |
Yes |
No |
Passes option x on to program cat |
-qoption c2 x |
Yes |
Yes |
No |
Passes option x on to program c2 |
-qoption as x |
Yes |
Yes |
No |
Passes option x on to program as |
-qoption asS x |
Yes |
Yes |
No |
Passes option x on to program asS |
-qoption ld x |
Yes |
Yes |
Yes |
Passes option x on to program ld |
-Qproduce .o |
Yes |
Yes |
Yes |
Produces type .o file (Object file) |
-Qproduce .s |
Yes |
Yes |
Yes |
Produces type .s file (Assembler source) |
-Qproduce .c |
Yes |
Yes |
No |
Produces type .c file (C source) |
-Qproduce .i |
Yes |
Yes |
Yes |
Produces type .i file (C source after cpp) |
-qproduce .o |
Yes |
Yes |
Yes |
Produces type .o file (Object file) |
-qproduce .s |
Yes |
Yes |
Yes |
Produces type .s file (Assembler source) |
-qproduce .c |
Yes |
Yes |
No |
Produces type .c file (C source) |
-qproduce .i |
Yes |
Yes |
Yes |
Produces type .i file (C source after cpp) |
-r |
Yes |
Yes |
No |
Makes relocatable; pass to linker |
-R |
Yes |
Yes |
No |
Merges data into text segment |
-R |
No |
No |
Yes |
Specifies search directories for the run-time linker |
-S |
Yes |
Yes |
+Yes |
Produces .s file only |
-s |
Yes |
Yes |
Yes |
Strips (4.1); pass to linker |
-sb |
Yes |
Yes |
-xsb |
Collects information for code browser |
-strconst |
No |
Yes |
No |
Places string literals in read-only text segment |
-sun2 |
Yes |
No |
No |
Generates code for a Sun-2(TM) system |
-sun3x |
Yes |
No |
No |
Generates code for a Sun-3x(TM) system |
-sun386 |
Yes |
No |
No |
Generates code for a Sun386i(TM) |
-sun3 |
Yes |
No |
No |
Generates code for a Sun-3 system |
-sun4c |
Yes |
No |
No |
Generates code for a Sun4c(TM) system |
-sun4 |
Yes |
No |
No |
Generates code for a Sun-4(TM) system |
-target |
Yes |
No |
-xtarget |
Sets target architecture to x |
-temp=dir |
Yes |
Yes |
Yes |
Set directory for temps to dir |
-time |
Yes |
Yes |
Yes |
Reports the execution times |
-u |
Yes |
Yes |
No |
Enters symbol arg as undef (ld) |
-Ux |
Yes |
Yes |
+Yes |
Undefines cpp symbol x |
-v |
Yes |
Yes |
Yes |
Verbose mode |
-v |
No |
No |
Yes |
Strict semantic checking |
-V |
Yes |
Yes |
+Yes |
Reports versions of programs |
-W |
No |
No |
No |
Arguments to other components |
-w |
Yes |
Yes |
Yes |
Does not print warnings |
-X[t,a,c,s] |
No |
Yes |
No |
Compatibility options |
-Y |
No |
No |
No |
Changes path name to components |
-yx |
Yes |
No |
No |
Traces symbol |
-z |
-assert |
-assert |
No |
Turns on asserts in linker |
-# |
-v |
-v |
No |
Verbose mode |
-EOF |
No |
No |
No |
File argument |
The C compiler accepts the types of file-name arguments shown in Table 15-2.
Table 15-2 File-name Extensions Used by the C Compiler
Suffix |
File Type |
---|---|
.a |
Object library |
.il |
In-line expansion file |
.o |
Object file |
.so |
Shared object |
.s |
Assembler source |
.S |
Assembler source for cpp |
.c |
C source |
.i |
C source after cpp |
"file.X=.Y" will read the file "file.X" but treat it as if it had suffix "Y"
There are several changes to the link editor, ld(1), in this release. The most important change is its ability to handle the new ELF native file format.
The recommended method for building libraries and executables is through the compiler driver rather than by invoking the linker directly. The compiler automatically supplies several files needed by the linker.
Some options have been renamed in the new linker, some have remained the same, and others are no longer needed. Table 15-3 compares the SunOS release 4.x ld command to the Solaris 2.6 ld command.
The sections following Table 15-3 explain how certain linking tasks are affected by the option differences.
Table 15-3 Comparison of ld Options
SunOS release 4.x Option |
Solaris 2.6 Replacement |
Notes |
---|---|---|
-align datum |
-M mapfile |
Uses mapfile and distinct sections |
-assert definitions |
Default |
|
-assert nodefinitions |
-znodefs |
Issues a fatal error instead of a warning |
-assert nosymbolic |
-zdefs |
Issues a fatal error instead of a warning |
-assert pure-text |
-ztext |
Issues a fatal error instead of a warning |
-A name |
No replacement |
dlopen(3X) and dlclose(3X) can approximate this behavior |
-Bdynamic |
-Bdynamic |
Applies only to the inclusion of shared libraries; use -dy (the default) to build dynamically linked executables. See "Building Executables". |
-Bnosymbolic |
-zdefs |
|
-Bstatic |
-dn & -Bstatic |
The -dn option must be specified to completely eliminate the dynamic linker. Use -Bstatic in dynamic mode to include archive libraries. (Used as a toggle. See "Building Executables".) |
-Bsymbolic |
-Bsymbolic |
Also gets -assert nosymbolic with this option |
-d -dc -dp |
Default |
Use -b option in SVR4 to turn off |
-D hex |
-M mapfile |
mapfile contains different mechanisms to accomplish desired effect |
-e entry |
-e entry |
|
no -e |
-G |
Creates a shared object |
-lx[.v] |
-lx |
Only major number versioning of shared libraries is currently supported |
-Ldir |
-Ldir |
dir not recorded in executable; use -R option instead. |
-M |
-m |
|
-n |
Default |
SVR4 executable format compresses disk image as -n |
-N |
No replacement |
|
-o name |
-o name |
|
-p |
Default |
Can override with -M mapfile |
-r |
-r |
|
-S |
No replacement |
|
-s |
-s |
|
-t |
No replacement |
|
-T hex |
-M mapfile |
mapfile contains different mechanisms to accomplish desired effect |
-Tdata hex |
-M mapfile |
mapfile contains different mechanisms to accomplish desired effect |
-u name |
-u name |
|
-x |
No replacement |
|
-X |
No replacement |
|
-y sym |
No replacement |
|
-z |
Default |
The procedure for building shared librariesin the Solaris 2.6 operating environment requires the -G option. In the SunOS release 4.x software, the linker would infer that a shared library was being built by the absense of the -e option. As shared libraries may have entry points, this option can no longer be used.
The -Bdynamic and -Bstatic options are still available, but their behavior is different. These options now refer to library inclusions to the executable rather than binding. Executable binding is set exclusively with the new -dy and -dn options in the Solaris 2.6 software. The -dy option is the default. It is required to create a dynamically linked executable. The -dn option is required to create a statically linked executable.
The -Bdynamic and -Bstatic options apply only when using the -dy option. -Bdynamic tells the link editor to include shared libraries, while -Bstatic tells it to include archive libraries. These options act as a toggle governing subsequent -l arguments until the next -Bdynamic or -Bstatic option is encountered.
The following examples show SunOS release 4.x and Solaris 2.6 commands that can be used to create similar executables.
sunos4.1% ld -Bstatic test.o -lx
Uses libx.a and creates a static executable
sunos5.x% cc -dn test.o -lx
Uses libx.a and creates a static executable
sunos4.1% ld -Bdynamic test.o -lx
Uses libx.so and creates a dynamic executable
sunos5.x% cc test.o -lx
Uses libx.so and creates a dynamic executable
sunos4.1% ld -Bdynamic test.o -Bstatic -lx
Uses libx.a and creates a dynamic executable
sunos5.x% cc test.o -Bstatic -lx
Uses libx.a and creates a dynamic executable
In the SunOS release 4.x software, directories specified with the -L option were searched at link time and the information retained for use at execution time. This behavior is now divided between the -L and -R options. The -L option specifies the directories to search at link time; the -R option tells the linker the search paths to be retained for use at run time. See "Search Path Rules", in the next section for more information.
As with the -Bdynamic and -Bstatic options, the position of the -L option has significance; it applies only to the subsequent -l options.
The dynamic linker and the runtime linker determine their search paths through a different algorithm from that used by the SunOS release 4.x linker.
The examples below compare the search paths for the dynamic linker and the runtime linker for SunOS release 4.x and the Solaris 2.6 operating environment. Notice that in the latter, the search path for the link editor and the runtime linker are affected by the LD_LIBRARY_PATH
setting.
SunOS release 4.x linker search paths:
Link Editor: -L, LD_LIBRARY_PATH
, /usr/lib, /usr/local/lib
Runtime Linker: LD_LIBRARY_PATH
, -L, /usr/lib, /usr/local/lib
Solaris 2.6 linker search paths (with LD_LIBRARY_PATH
=dirlist1):
Link Editor: -L, dirlist1, /usr/ccs/lib, /usr/lib
Runtime Linker: dirlist1, -R, /usr/lib
Solaris 2.6 linker search paths (with LD_LIBRARY_PATH
=dirlist1,dirlist2):
Link Editor: dirlist1, -L, dirlist2, /usr/ccs/lib, /usr/lib
The SunOS release 4.x software supported both major and minor version numbers on shared libraries. The Solaris 2.6 operating environment supports only the major version number. For binary compatibility support, major and minor version numbers are recognized on SunOS release 4.x shared libraries. These libraries are required to retain the same major and minor version number they had in the SunOS release 4.x software.
Table 15-4 shows versions of SunOS release 4.x and Solaris 2.6 shared libraries.
Table 15-4 Example Shared Libraries
SunOS release 4.x |
Solaris 2.6 |
---|---|
libc.so.1.7 |
libc.so.1 |
libdl.so.1.0 |
libdl.so.1 |
In SunOS release 4.x system software, when the -l option was specified, the build environment linker searched for a library with both major and minor numbers. For example, if -ldl was specified, the library, libdl.so.1.0 was linked. In the Solaris 2.6 environment, even though major numbers are still supported, the default behavior of the link editor is to ignore version numbers. Using the previous example, the build environment link editor now searches for libdl.so and a symbolic link points to a specific version file.
The recording of a dependency in a dynamic executable or shared object is, by default, the file name of the associated shared object as it is referenced by the link editor. To provide a more consistent means of specifying dependencies, shared objects can record within themselves the file name by which they should be referenced at runtime. This is specified with the -h option when linking the library file.
Symbolic links have been created for most libraries in this release. You should build any new shared libraries with major numbers, then create a symbolic link to the version of the library that is used most often.
A new utility, dump(1), makes it easier to debug object files or to check the static and dynamic linking, see "Backing Up and Restoring Files"). The dump -L option displays the information needed by the runtime linker that is contained in the executable. This information is contained in the dynamic section of an ELF file. The RPATH
entry displays search paths specified by the -R option to ld.
The following example:
Creates a link from libx.so.1 to libx.so
Shows dump output, including the SONAME
field, which stores the information passed with the -h option.
examples% cc -G -o libx.so.1 -h libx.so.1 libx.o examples% cp libx.so.1 /mylibs examples% ln -s /mylibs/libx.so.1 /mylibs/libx.so examples% dump -Lv libx.so.1 libx.so.1: **** DYNAMIC SECTION INFORMATION **** .dynamic : [INDEX] Tag Value [1] INIT 0x3b8 [2] FINI 0x3f4 [3] SONAME libx.so.1 [4] HASH 0x94 [5] STRTAB 0x33c [6] SYMTAB 0x14c [7] STRSZ 0x62 [8] SYMENT 0x10 [9] PLTGOT 0x10404 [10] PLTSZ 0xc [11] PLTREL 0x7 [12] JMPREL 0x3ac [13] RELA 0x3a0 [14] RELASZ 0x18 [15] RELAENT 0xc |
If a library needs other dynamic libraries, they should be specified along with an RPATH
, as the next example shows.
The next example compiles prog.c, dynamically linking libx.so (as built in the previous example), and specifies that the binary retain the current directory information for execution. This example shows the output of dump from the compiled program, prog.c. Here, the information stored in the SONAME
field of the previous example is shown as NEEDED
by prog. When prog is run, it will use libx.so.1 even if libx.so is linked to a different version.
examples% cc -o prog prog.c -L/mylibs -R/mylibs -lx example% dump -Lv prog prog: **** DYNAMIC SECTION INFORMATION **** .dynamic : [INDEX] Tag Value [1] NEEDED libx.so.1 [2] NEEDED libc.so.1 [3] INIT 0x1b1ac [4] FINI 0x1b248 [5] RPATH /mylibs [6] HASH 0x100e8 [7] STRTAB 0x17f90 [8] SYMTAB 0x12be0 [9] STRSZ 0x31e1 [10] SYMENT 0x10 [11] DEBUG 0x0 [12] PLTGOT 0x2b25c [13] PLTSZ 0x30 [14] PLTREL 0x7 [15] JMPREL 0x1b180 [16] RELA 0x1b174 [17] RELASZ 0x3c [18] RELAENT 0xc |
This section describes changes to debugging tools.
The dbx and dbxtool tools are no longer available with default system software. Enhanced versions of these tools are available as part of Sun WorkShop(TM), an unbundled product.
The adb and kadb tools are available in the Solaris 2.6 operating environment. They offer the same capabilities as the SunOS release 4.x tools. kadb has been enhanced to recognize multiple processors. The processor ID is displayed in the kadb prompt. In the following examples, it is 0.
To make kernel debugging under the Solaris 2.6 operating environment easier:
Enable savecore (uncomment the savecore lines in the /etc/init.d/sysetup file)
Boot under kadb (type $c when the system crashes)
Use adb and crash
The kadb macros described below are particularly useful with the new multithreaded kernel.
thread displays the current thread. The current thread pointer is in SPARC global register g7.
kadb[0]: <g7$<thread |
threadlist shows the stack traces of all the kernel threads in the system. This can be a long list.
kadb[0]: $<threadlist |
mutex shows you the address of the owning thread. The following example uses the global unsafe driver mutex.
kadb[0]: unsafe_driver$<mutex |
kadb[0]: moddebug/W 0x80000000 |
moddebug enables you to watch module loading. See the end of <sys/modctl.h> for legal values for moddebug for debugging purposes only.
Use the following command to debug a live kernel.
# adb -k /dev/ksyms /dev/mem |
/dev/ksyms is a pseudo device that contains the complete name list of the running kernel.
truss is a new utility, provided to trace system calls performed, signals received, and machine faults incurred. truss offers several significant improvements over the SunOS release 4.x trace(1) command, including the ability to follow forked processes and to deal with multithreaded processes.
The following example shows a summary of traced calls for the date command. With the -c option, truss does not display the trace line by line. Instead, it counts the system calls, signals, and faults, and displays a summary.
example% truss -c date Fri Sep 18 14:31:30 PDT 1992 syscall seconds calls errors _exit .00 1 read .00 7 write .00 1 open .03 12 close .00 12 time .00 1 brk .01 4 lseek .00 1 fstat .00 4 ioctl .00 1 execve .00 1 mmap .01 17 munmap .00 8 ---- --- --- sys totals: .05 70 0 usr time: .03 elapsed: .28 |
See the truss(1) man page for complete details on all truss options. There are a number of other Solaris 2.6 debugging tools based on proc(4) such as pmap(1).
This chapter discusses the changes to tools and resources for the development environment.
All ioctls related to dkio(7I), filio, mtio(7I), sockio(7I), streamio(7I), termio(7I), and termios(7I) are supported in this release.
A few incompatibilities exist between the SunOS release 4.x termios structure and Solaris 2.6 termios structure. For example, the Solaris 2.6 termios structure does not include a c_line field.
The following ioctls requests, defined in <sys/ttold.h>, are not implemented in this release.
TIOCMODG
OTTYDISC
TABLDISC
KBLDISC
TIOCMIDS
TIOCSETX
NETLDISC
NTABLDISC
TIOCGETX
NTTYDISC
MOUSELDISC
The following ttycom ioctl requests are not in the Solaris 2.6 operating environment.
TIOCSCTTY
TIOCNOTTY
TIOCISPACE
TIOCPKT
TIOCGETPGRP
TIOCISIZE
TIOCUCNTL
TIOCOUTQ
TIOCTCNTL
TIOCCONS
Table 16-1 shows the ioctls supported in the Solaris 2.6 operating environment.
Table 16-1 ioctl() Support
The ptrace() facility is implemented on top of /proc. New applications should use proc(4) directly.
The ptrace() routine in Solaris 2.6 software is present solely to support applications running in BCP mode. It uses integers 1 - 9 as request values, while the SunOS release 4.x routine defines request values as symbolic constants in <sys/ptrace.h>. The following SunOS release 4.x request symbolic constants are compatible with Solaris 2.6 software.
PTRACE_TRACEME
PTRACE_PEEKTEXT
PTRACE_PEEKDATA
PTRACE_PEEKUSER
PTRACE_POKETEXT
PTRACE_POKEDATA
PTRACE_POKEUSER
PTRACE_CONT
PTRACE_KILL
PTRACE_SINGLESTEP
The SunOS release 4.x PTRACE_CONT addr argument specifies where the stopped process should resume execution, unless addr = 1, in which case execution resumes from where the process had stopped. The equivalent Solaris 2.6 request 7 requires that addr always be equal to 1 and that execution always resumes from where the process stopped. Also, the Solaris 2.6 request 7 cancels all pending signals before the process resumes execution except those specified by data. The SunOS release 4.x PTRACE_CONT does not cancel all pending signals.
Table 16-2 shows SunOS release 4.x valid requests that are not supported by the Solaris 2.6 ptrace() routine.
Table 16-2 ptrace() Requests not Supported by Solaris 2.6 Software
PTRACE_ATTACH |
PTRACE_GETWINDOW |
PTRACE_DETACH |
PTRACE_SETWINDOW |
PTRACE_GETREGS |
PTRACE_22 |
PTRACE_SETREGS |
PTRACE_23 |
PTRACE_GETFPREGS |
PTRACE_26 |
PTRACE_SETFPREGS |
PTRACE_27 |
PTRACE_READDATA |
PTRACE_28 |
PTRACE_WRITEDATA |
PTRACE_SYSCALL |
PTRACE_READTEXT |
PTRACE_DUMPCORE |
PTRACE_WRITETEXT |
PTRACE_SETWRBKPT |
PTRACE_GETFPAREGS |
PTRACE_SETACBKPT |
PTRACE_SETFPAREGS |
This release is compliant with the System V Interface Definition, Third Edition (SVID 3). Programs written with the SunOS release 4.1 System V libraries are easy to port to this release. Programs using the SunOS release 4.x BSD C library require more effort.
Several functions and groups of functions were moved into different libraries. This can cause references to these functions to be flagged as undefined when compiling a SunOS release 4.x application in the Solaris 2.6 environment.
After a compile, check the man page of any functions flagged as undefined. The synopsis list both the -l linker option and any include files that you need to resolve the symbol.
Shared libraries do not currently support minor version numbers.
Files for shared initialized data (.sa) are no longer required; no .sa files are provided with the Solaris 2.6 software.
The Solaris 2.6 operating environment handles resource limits differently. In previous releases, static table allocations were used for resources such as file descriptors and active processes. These resources are now dynamically allocated, so they are limited by the physical memory available. Table 16-3 shows the resource limits.
Table 16-3 Resource Limits
Configuration |
Limitation |
---|---|
|
Maximum size of core file (in bytes) that can be created by a process |
|
Maximum amount of CPU time (in seconds) that a process can use |
|
Maximum size of a process's heap (in bytes) |
|
Maximum size of a file (in bytes) that can be created by a process |
|
One more than the maximum number of file descriptors that can be created by a process |
|
Maximum size (in bytes) to which a process's mapped address space may grow |
|
Maximum size (in bytes) of a process's stack |
Any shared objects that need the networking libraries must be dynamically linked. The networking libraries require libdl.so.1. An archive library is not available.
Table 16-4 shows SunOS release 4.x and Solaris 2.6 libraries and their locations.
Table 16-4 Comparison of Library Locations
Library Name |
SunOS release 4.x Directory |
Solaris 2.6 Directory |
---|---|---|
libbsdmalloc.a |
/usr/lib |
/usr/lib |
libc.a |
/usr/lib and /usr/5lib |
/usr/lib |
libc.so.1.7 |
/usr/lib |
/usr/lib |
libc.so.2.7 |
/usr/5lib |
/usr/lib |
libc_p.a |
/usr/5lib |
Not available |
/usr/lib and /usr/5lib |
/usr/ucblib and /usr/ccs/lib |
|
libcurses_p.a |
/usr/5lib |
Not available |
libdbm.a |
/usr/lib |
/usr/ucblib |
libdl.so.1.0 |
/usr/lib |
/usr/lib |
libg.a |
/usr/lib |
Not available |
libkvm.a |
/usr/lib |
Not available |
libkvm.so.0.3 |
/usr/lib |
/usr/lib |
libl.a |
/usr/lib |
/usr/ccs/lib |
libln.a |
/usr/lib |
Not available |
liblwp.a |
/usr/lib |
Not available |
/usr/lib |
/usr/lib and /usr/lib/libp |
|
libmp.a |
/usr/lib |
/usr/lib |
libnbio.a |
/usr/lib |
Not available |
libnsl.a |
/usr/lib |
/usr/lib |
libpixrect.a |
/usr/lib | |
libpixrect.so.2.14 |
/usr/lib |
Not available |
libposix.a |
/usr/lib |
Not available |
libresolv.a |
/usr/lib |
/usr/lib |
librpcsvc.a |
/usr/lib |
/usr/lib |
libsuntool.so.0.54 |
/usr/lib |
Not available |
libsunwindow.so.0.55 |
/usr/lib |
Not available |
/usr/5lib |
Not available |
|
libsvidm_p.a |
/usr/5lib |
Not available |
/usr/lib and /usr/5lib |
/usr/ucblib and /usr/ccs/lib |
|
libtermlib.a |
/usr/lib and /usr/5lib |
/usr/ccs/lib |
libxgl.so.1.1 |
/usr/lib |
/opt/SUNWits/ Graphics-sw/xgl/lib |
/usr/xpg2lib |
Not available |
|
liby.a |
/usr/lib and /usr/5lib |
There are two make utilities available in the Solaris 2.6 operating environment. The default version, /usr/ccs/bin/make, is identical to the SunOS release 4.x make command. The SVR4 version is available in /usr/ccs/lib/svr4-make.
Using the default version, your Makefiles will not need changes. However, some of the commands used in your Makefiles may have changed. For example, install(1), commonly used in Makefiles, could produce unexpected results because of changes to the options, as shown in the following examples.
In a SunOS release 4.x Makefile - install:
install -o bin -g bin -m 444 target.c /usr/bin/target |
In a SunOS release 5.6 Makefile - install:
install -u bin -g bin -m 444 target.c /usr/bin/target |
The version of install(1B) in /usr/ueb is compatible with the SunOS release 4.x version.
Check the compatibility tables in Appendix A, Commands Reference Table, for information about individual interfaces.
The Solaris 2.6 operating environment source code control system (SCCS) is slightly different from the SunOS release 4.x version. The same set of commands and subcommands are supported in both environments. SCCS directories and s.files used on SunOS release 4.x systems work equally well on Solaris 2.6 systems.
In the SunOS release 4.x software, the SCCS commands were located in the /usr/sccs directory. These commands are located with the other programming tools in /usr/ccs/bin in the Solaris 2.6 operating environment.
One difference between SunOS release 4.x and Solaris 2.6 utilities is the handling of unreadable s.files. The SunOS release 4.x commands print an error and continue when they encounter an unreadable s.file. The Solaris 2.6 commands silently ignore the error.
Although the Binary Compatibility Package is not provided as a development environment, it requires sound programming practices that can improve binary compatibility with future releases.
The Binary Compatibility Package provides compatibility for dynamically linked and statically linked applications, as well as hybrids that are partially static and partially dynamically linked.
The Binary Compatibility Package works with well-behaved user applications. Well-behaved applications do not:
Trap directly to the kernel
Write directly to any system files
Use /dev/kmem, /dev/mem, or libkvm
Use unpublished SunOS interfaces
Rely on customer-supplied drivers
Applications that are not well-behaved can produce unpredictable results.
Information on using the Binary Compatibility Package is available in Binary Compatibility Guide.
The Solaris 2.6 operating environment is bundled in units called packages. These packages contain all the files and information you need to add or remove software from your system.
A package consists of the following components:
pkginfo file - This is an ASCII file that sets characteristics of the package. It consists of a list of macro=value pairs that describe the package and set control parameters for its installation. See the pkginfo(4) man page for more information.
prototype file - This is an ASCII file that defines the contents of the package. It contains one entry for each deliverable object (for example, files, directories, and links). It also contains installation entries for package information files-such as pkginfo, depend, and copyright-and scripts. See the prototype(4) man page for more information.
copyright file -This is an ASCII file that provides a copyright notice for the package. Its contents (including comment lines) are displayed during package installation. See the copyright(4) man page for more information.
Package contents - The contents of the package.
Scripts - Scripts can be used to control installation or removal of a package, to request input from the user, or to perform an action on all objects of a particular class. Scripts must be executable by the Bourne shell.
Add-on application software should be packaged so it can be installed on a Solaris 2.6 system from diskette, tape, or CD-ROM. Application Packaging Developer's Guide provides guidelines for building your packages.
Several utilities are provided to create and manipulate packages. Table 16-5 lists commands that are useful for creating packages.
Table 16-5 Commands for Creating Packages
Generates prototype file entries for input to the pkgmk command |
|
Produces an installable package |
|
Translates package format |
Table 16-6 lists commands that are useful for adding and removing packages.
Table 16-6 Commands for Adding and Removing Packages
Adds software package to the system |
|
Stores answers to a request script |
|
Removes a package from the system |
|
Checks accuracy of installation |
Table 16-7 lists commands that provide information about packages.
Table 16-7 Commands for Providing Information About Packages
Displays software package information about installed packages |
|
This section discusses OPEN LOOK Intrinsics ToolKit (OLIT) and XView.
The OPEN LOOK Intrinsics Toolkit (OLIT) is based on Xt Intrinsics. It provides a set of functions common to many widget sets to create, employ, and destroy user interface components for an X environment.
The XView Window Toolkit provides an implementation of the OPEN LOOK Graphical User Interface (GUI) specification. It provides a migration path for SunView applications.
XView uses variable-length attribute-value lists based on varargs to specify objects to be created, such as windows, menus, and scrollbars. This eliminates most of the boilerplate software usually found in procedural interfaces, since the usual behavior is already defined.
Most SunOS release 4.x programming tools are still available and stil provide the same capabilities, but many are in new locations. All bundled programming tools are now in the /usr/ccs/bin library except cpp, which is now in the /usr/ccs/lib library. Table 16-8 shows the programming tools and their SunOS release 4.x locations.
Table 16-8 Bundled Programming Tools
SunOS release 4.x Command |
SunOS release 4.x Location |
---|---|
/usr/sccs |
|
/usr/bin |
|
/usr/bin |
|
/usr/sccs |
|
/usr/sccs |
|
/usr/lib/cpp |
|
/usr/sccs |
|
/usr/ucb |
|
/usr/sccs |
|
/usr/sccs |
|
/usr/bin |
|
/usr/bin |
|
/usr/bin |
|
/usr/bin |
|
/usr/bin |
|
/usr/bin |
|
/usr/bin |
|
/usr/sccs |
|
/usr/sccs |
|
/usr/bin |
|
/usr/sccs |
|
/usr/sccs |
|
/usr/ucb |
|
/usr/sccs |
|
/usr/bin |
|
/usr/bin |
|
/usr/ucb |
|
/usr/bin |
|
/usr/sccs |
|
/usr/ucb |
|
/usr/sccs |
|
/usr/old |
|
/usr/sccs |
|
/usr/bin |
|
/usr/lib |
Table 16-9 lists the new Solaris 2.6 programming tools and their descriptions.
Table 16-9 New Programming Tools
New Command |
Description |
---|---|
Object code disassembler |
|
Dumps selected parts of an object file |
|
Extracts strings from source files |
|
Manipulates the comment section of an object file |
|
Regular expression compiler |
|
Traces system calls and signals |
|
ptools |
Miscellaneous /proc utilities |
Table 16-10 lists the SunOS release 4.x commands that are now unbundled.
Table 16-10 Unbundled Programming Tools
Unbundled Command |
Description |
---|---|
Simple C program beautifier |
|
C compiler |
|
Generates a flow graph for a C program |
|
Interactively examines a C program |
|
Generates a C program execution trace |
|
Generates a C program cross-reference |
|
Source-level debugger |
|
Window-based source-level debugger |
|
Displays call-graph profile data |
|
Indents and formats C program source files |
|
In-line procedure call expander |
|
C program verifier |
|
Dumps selected parts of a COFF object file |
|
Constructs test coverage analysis and statement-by-statement profile |
This chapter discusses Solaris 2.6 networking features as they relate to the programming environment, and it discusses issues concerning the improved internationalization features.
The Solaris 2.6 operating environment includes the following networking features:
Distributed file system (DFS), which centralizes the file system utilities
Network information services plus (NIS+) including NFS
Name service switch file
See NIS+ Transition Guide and NFS Administration Guide for more information on using these services.
The Solaris 2.6 operating environment supports the network information service (NIS), the SunOS 4.x name service, and the network information services plus (NIS+), an enterprise-naming service of heterogenous distributed systems. See "NIS+ " for the nature of NIS+ support available in the Solaris 2.6 operating environment.
NIS+ provides a more detailed model for objects in the name space, improved security, and faster updates than NIS.
The NIS+ programmer interfaces are documented in section 3N of the man Pages(3): Library Routines.
The nsswitch.conf file simplifies name service administration. Applications can use this file to select a name service. This information no longer needs to be hard-coded into the service itself. See the nsswitch.conf(4) man page for more information on the format of this file.
The Network Interface Tap (NIT) provided in the SunOS 4.x release is no longer required. Now Ethernet drivers are real STREAMS drivers that can be opened and communicated with directly.
See pfmod(7M), bufmod(7M), and dlpi(7P)
The Solaris 2.6 Ethernet drivers and other data link drivers support the connectionless Data Link Provider Interface (DLPI) Version 2 specification.
Sockets are supported in the Solaris 2.6 operating environment. Unlike the SunOS release 4.x software, sockets are no longer implemented completely in the kernel. They are now in a library, libsocket, implemented on STREAMS.
Most of the changes in the Solaris 2.6 operating environment improve on previous internationalization features. For complete information on internationalization support, see Developer's Guide to Internationalization.
Application developers concerned with internationalizing their programs should follow these guidelines:
Call setlocale(3C) to set up the LANG
environment variable
Use standard code sets and follow 8-bit boundaries
Use strftime(3C) to print the date and time
Replace strcmp(3) with strcoll(3C) for user-visible collation
Call gettext(3C) or catget(3C) to retrieve translated strings from locale-specific message catalogs
The Solaris 2.6 operating environment supports extended UNIX code (EUC), VTF8, PCK, and B165. This allows multibyte and multiple code sets on one system.
The SunOS release 4.x software supported single-byte representation of non-ASCII characters. The Solaris 2.6 operating environment supports multibyte representation. This support is needed for Asian language character sets, which contain thousands of characters.
The multibyte functions are included in libc and provides the following features:
Multibyte-to-wide character conversions
Wide character standard I/O
Wide character classification
Wide character formatting
The Solaris 2.6 operating environment supports multibyte file names; however, login and machine names should be restricted to ASCII characters.
SunOS release 4.x support for message catalogs is enhanced in the Solaris 2.6 operating environment to enable the creation of message catalogs using multibyte characters.
Using message catalogs, an application can display messages at run-time in the native language in which an application was run. These message catalogs must first be created for the native language specified by the language locale.
The SunOS release 5.6 locale database (/usr/lib/locale/locale) is completely different than the locale database of SunOS 5.x. This is transparent to the user, however.
Most of the system commands in the Solaris 2.6 operating environment have been messaged. Many of these commands can pass through multibyte character representations. The increased number of messaged commands makes localization efforts easier.
The installtxt(1) command has been replaced with msgfmt(1). Use the new xgettext(1) command to extract messages.
Changes to strftime(3C) affect date and time formats. Shell programs that rely on the output format of the date(1) command will have to be updated to handle the new format.
chrtbl(8) and catdef(8) are replaced by localedef(1).
The /usr/xpg2lib/libxpg2.a archive library is no longer available. These routines have been included in libc.
Table 17-1 shows the new location of these interfaces.
Table 17-1 xpg2lib Library Routine Locations
Routine |
Solaris 2.6 Location |
---|---|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
Not supported. |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
|
/usr/lib/libc |
Programs that use these routines no longer need to pass -lxpg2 to the C compiler although some may need to include libintl.h. (See Table 17-1 for these routines.)
The catgetmsg(3C) routine is no longer available.
The order of locale categories in the string returned by setlocale(3C) differs between the SunOS release 4.x and the Solaris 2.6 software. This string is normally used by a subsequent call to setlocale(3C), and the order should not matter. Applications should not rely on a specific order of locale categories.
The operating system kernel and its interfaces have changed significantly. Binary compatibility is not provided for SunOS release 4.x device drivers. This chapter discusses changes in the Solaris 2.6 operating environment that affect kernel and system developers.
Changes related to system configuration include the dynamically loaded kernel and kernel layout, the config and boot commands, and the /etc/system file.
Unlike previous SunOS releases, the kernel is now dynamically configured. The kernel now consists of a small static core and many dynamically loadable kernel modules. Drivers, file systems, STREAMS modules, and other modules are loaded automatically as needed, either at boot time or at runtime. When these modules are no longer in use, they may be unloaded. Modules are kept in memory until that memory is needed. modinfo(1M) provides information about the modules currently loaded on a system.
The modload(1M) and modunload(1M) commands are still available in this release but they perform differently. They have more limited usage and are no longer sufficient to correctly install a loadable driver onto the system. modunload now includes the capability to unload all unloadable (and not busy) modules. Use modunload as follows.
# modunload -i 0 |
The contents of the kernel, which were formerly in a single file, /vmunix, are now contained in modules in a directory hierarchy. By default, the directory hierarchy is/platform/'uname -i'/kernel, /kernel, and /usr/kernel.
The directory search path for modules can be set by the moddir
variable in the /etc/system file (see the system(4) man page). Typically, /platform/'uname -i'/kernel/unix is the first portion of the kernel to be loaded (see the kernel(1M) man page).
In the SunOS release 4.x software, the config command was used to generate system configuration files that enabled /vmunix to be relinked from object files. The need for this command has been removed by the following Solaris 2.6 features:
Loadable modules
The /etc/system file (see the system(4) man page)
Device tree information from the OpenBoot PROM (OBP)
The driver.conf files in /kernel/drv and /usr/kernel/drv
System configuration information is now set in the /etc/system file. This file also modifies the kernel's treatment of loadable modules. The file contains commands of the form:
set parameter=value
For example, in the SunOS release 4.x software, MAXUSERS
was set using config(8). In the Solaris 2.6 operating environment, it is set in the /etc/system file with the following line:
set maxusers = number |
Commands that affect loadable modules are of the form:
set module:variable=value
Changes made to the /etc/system file only take effect when you reboot your system (see the system(4) man pages).
In this release, the following boot programs are available:
inetboot - To boot from across the network
When booting from a disk, the PROM assumes that the primary boot block resides in blocks 1 - 15 of the local disk. Use installboot(1M) to create the boot block:
# installboot /usr/platform/'uname -i'/lib/fs/ufs/bootblk \ /dev/rdsk/c0t3d0s0 |
The system firmware loads the primary bootstrap (the boot block) program into memory and runs it. The boot block is a UFS file system reader. It loads the secondary boot program (/platform/'uname -i'/ufsboot) into memory.
ufsboot loads kernel/unix, then /kernel/unix uses ufsboot to load modules from the kernel directory hierarchy until it is able to mount the root file system.
During these operations, the boot block and ufsboot use the drivers provided by the firmware; neither ufsboot nor the boot block contains any driver code. The ufsboot code does not have to change to incorporate a new SBus card with a new disk type since ufsboot uses the SBus card PROM driver.
When booting over the network, the boot program performs as it did for a diskless boot in the SunOS release 4.x software. However, the boot program is now called inetboot and the client vfstab file entries are different. See System Administration Guide for information on diskless booting.
Table 18-1 summarizes the differences in the boot sequence between the SunOS release 4.x and the Solaris 2.6 operating environment.
Table 18-1 Summary of Boot Differences
SunOS release 4.x |
Solaris 2.6 |
Description |
---|---|---|
bootblk |
Loads ufsboot from disk |
|
ufsboot |
Loads unix from disk |
|
unix |
Bootable kernel image |
|
inetboot |
Mounts and copies unix from network |
|
/etc/rcS |
Mounts /usr and checks file systems |
|
/etc/rc2, /etc/rc3, /etc/rc2.d, /etc/rc3.d |
System configuration scripts |
|
modload, /etc/system, add_drv, rem_drv |
Customizes system kernel; loads, adds, and removes modules as needed |
|
PROM monitor, single user, multiuser |
Run states 0 - 6, and S |
A reconfiguration boot tells the system to probe for all connected devices and build the names for them in /devices and /dev. A reconfiguration boot, performed when adding new hardware to the system, is triggered by booting with the -r option:
ok> boot -r |
If another device of an existing type (with the driver already installed) is added, and you forget to do a reconfiguration boot, you can use the following commands to tell the system to recognize the new device.
# touch /reconfigure # _INIT_RECONFIG=YES /etc/init.d/drvconfig # _INIT_RECONFIG=YES /etc/init.d/devlinks |
This section expands on the discussion in "Device Naming Conventions", focusing on aspects of device naming that concern system and kernel developers.
The /devices tree represents the tree of devices recognized by the kernel. This tree is configured by the drvconfig(1M) program. drvconfig is normally run only when the system is booted with the -r flag (see "Reconfiguration Boot"). drvconfig configures /devices with information about devices (with drivers) that are connected and ready at boot time.
Entries are exported by device drivers calling ddi_create_minor_node(9F) when they have determined that a device exists.
Use the add_drv(1M) command to add a device to the system. If the driver was successfully added, add_drv will also run drvconfig.
In this release, /dev is managed by utility programs that create symbolic links to the real entries in /devices. The programs are:
disks(1M)
tapes(1M)
ports(1M)
devlinks(1M)
You can run a script to create the appropriate links from /dev to /devices. The /dev names have the advantage of being simpler and more familiar, while the /devices names are unique names for the hardware.
Each device in the system is driven by a device driver. Device drivers manage many instances of a device. Devices are named in several ways:
Physical names
Logical names
Instance names
Physical names are stored in /devices. They describe the hardware, and vary with the platform and configuration. For example:
/devices/vme/xdc@6d,ee80/xd@0,0:g
Physical names can be used to identify which piece of hardware is in use. For example, xdc@6d,ee80 refers to the disk controller at address 0xee80 in VME A16, D32 space. See the vme(4) and driver.conf(4) man pages.
Logical names are stored in /dev. They attempt to abstract most of the nature of physical device names that are specific to the platform. Logical names might be appropriate for an xd device, such as:
/dev/dsk/c2d0s6 (controller 2, slave 0, slice 6 (4.x partition "g"))
or an sd device, such as:
/dev/dsk/c0t3d0s0 (controller 0, target 3, lun 0, slice 0 (4.x partition "a"))
The logical name conveys nothing about the type of controller. It does not differentiate between SCSI and IPI; they are both just disks.
Disk names use the SVR4 convention of slice numbers 0-7 instead of the letters a-h used in the SunOS release 4.x software.
Disk names also use the SVR4 convention of /dev/dsk/* for block disk devices and /dev/rdsk/* for raw disks. For more information, see System Administration Guide.
Instance names refer to the nth device in the system (for example, sd20).
Instance names are occasionally reported in driver error messages. You can determine the binding of an instance name to a physical name by looking at dmesg(1M) output, as in the following example.
sd9 at esp2: target 1 lun 1 sd9 is /sbus@1,f8000000/esp@0,800000/sd@1,0 <SUN0424 cyl 1151 alt 2 hd 9 sec 80> |
Once the instance name has been assigned to a device, it remains bound to that device.
Instance numbers are encoded in a device's minor number. To keep instance numbers persistent across reboots, the system records them in the /etc/path_to_inst file. This file is read only at boot time, and is currently updated by the add_drv(1M) and drvconfig(1M) commands. See the path_to_inst(4) man page for more information.
This chapter discusses device driver issues such as changes to device driver interfaces, the devinfo command, porting considerations, STREAMS, and Solaris 2.6 driver architecture.
See the following guides for more information on the topics discussed in this chapter:
Some of the many changes to device drivers in the Solaris 2.6 operating environment include the new DDI/DKI routines, Solaris SPARC DDI-specific routines, new software properties, and loadable drivers. In addition, many previous device issues have become opaque to the driver including interrupts, DVMA, and memory mapping.
In previous SunOS releases, a driver writer had to cope with changes in the device driver interfaces. Usually, there was a porting effort with each release of the operating system. In addition, the interfaces for each platform varied, so device drivers often required separate releases for each platform. Third-party device driver releases often included complex scripts that would reconfigure and rebuild the operating system in order to integrate a device driver. It was costly to support and maintain device drivers.
Unlike previous releases of SunOS systems (SunOS release 4.1.3 software and earlier), the device driver interfaces in the Solaris 2.6 operating environment are formalized and are referred to as the Solaris 2.6 SPARC DDI/DKI. The Solaris 2.6 SPARC DDI/DKI provides binary compatibility of device drivers across all supported platforms and for all future releases of the Solaris 2.6 operating environment on those platforms.
The term DDI/DKI is derived from the original specification as supplied in the SVR4 release. It stands for device driver interface/driver kernel interface. The interfaces are divided into three groups:
DDI/DKI
DKI only
DDI only
The DDI/DKI interfaces were standardized in SVR4, and are generic across all implementations of SVR4, regardless of the platform on which they are running.
The DKI-only interfaces are generic like the DDI/DKI interfaces and are supported in all SVR4 implementations. However, they are not guaranteed to be supported in future releases of System V.
The DDI-only interfaces are intended to be architecture-specific; for example, methods to access and control-device and system-specific hardware (that is, I/O registers, DMA services, interrupts, and memory mapping). These interfaces are not guaranteed to work in other SVR4 implementations.
This group of features effectively lowers the cost of driver support and maintenance. These features, combined with the large number of SPARC platforms, are helpful to many new third-party hardware developers.
With this level of binary compatibility, third-party hardware developers can now "shrink-wrap" their DDI-compliant device drivers with their driver hardware. Installing a new driver package can now be entirely automated. The self-configuring kernel removes the necessity for recompiling the kernel to add or remove a driver. Thus, DDI-compliant device driver for Solaris 2.6 environments can be treated like any other consumer software product.
In the Solaris 2.6 DDI/DKI the DDI-only interfaces are generic to all systems that support the Solaris 2.6 DDI/DKI. Note that the interfaces that make up the Sun common SCSI architecture (SCSA), and the locking interfaces used to make the driver behave correctly in a multithreaded kernel are also considered DDI-only interfaces in the Solaris 2.6 operating environment.
SCSA shields device drivers from details specific to the platform relating to host adapter implementations. With SCSA, a SCSI driver can run on all supported platforms.
A device driver that restricts itself to using only interfaces in the previous categories above is said to be Solaris 2.6 DDI/DKI compliant. A Solaris 2.6 DDI/DKI compliant device driver is commonly referred to as a DDI-compliant device driver.
The man pages for the driver routines, structures, and support routines that comprise the DDI/DKI can be found in the sections of man Pages(1M): System Administration Commands listed below. See the Intro(9) man page for more information about these sections.
Section 9E - Driver entry points
Section 9F - Driver support functions
A Device Driver Developers Kit (DDK) is available separately.
The Solaris 2.6 devinfo command performs a different function from the SunOS release 4.x version. The new prtconf(1M) command provides the information that the SunOS release 4.x devinfo command formerly displayed. The following examples show the output of each command.
4.1system% devinfo Node 'SUNW,Sun 4/50', unit #0 (no driver) Node 'packages', unit #0 (no driver) Node 'openprom', unit #0 (no driver) Node 'zs', unit #0 Node 'zs', unit #1 Node 'audio', unit #0 Node 'eeprom', unit #0 (no driver) Node 'counter-timer', unit #0 (no driver) Node 'memory-error', unit #0 (no driver) Node 'interrupt-enable', unit #0 (no driver) Node 'auxiliary-io', unit #0 (no driver) Node 'sbus', unit #0 Node 'dma', unit #0 Node 'esp', unit #0 Node 'sr', unit #0 Node 'sd', unit #0 Node 'le', unit #0 Node 'cgsix', unit #0 Node 'memory', unit #0 (no driver) Node 'virtual-memory', unit #0 (no driver) Node 'fd', unit #0 Node 'options', unit #0 (no driver) |
With the self-configuring kernel, Solaris 2.6 drivers will look more like SBus drivers than other types. All drivers are loadable, and no kernel configuration is required.
Under the SunOS release 4.x software, only one processor could be in the kernel at any one time. This was accomplished by using a master lock around the entire kernel. When a processor wanted to execute kernel code, it would acquire the lock (excluding other processors from running the code protected by the lock) and it would release the lock when it finished.
The Solaris 2.6 kernel is multithreaded. Instead of one master lock, there are many smaller locks that protect smaller regions of code. For example, there may be a kernel lock that protects access to a particular vnode, and one that protects an inode. Only one processor can be running code dealing with that vnode at a time, but another could be accessing an inode. This allows a greater amount of concurrency.
The multithreaded kernel will have a major impact on how you design the driver. The old model of using splN/splr pairs no longer works (on a uniprocessor or a multiprocessor system [Strictly speaking, the splN/splr pair do work; however, although they will block interrupts, the effect is useless in protecting data structures in a multiprocessor environment.] ). Instead, you have a choice of MT-style locks. The most common of these for drivers will be mutual exclusion locks, mutexes, and condition variables (which are an approximate equivalent of sleep()/wakeup() synchronization).
The old notion that you owned the processor until you explicitly called sleep() is no longer true. Because of kernel pre-emption, the CPU is switched from thread to thread so you must use the appropriate MT lock primitives to guard against concurrent access to device registers, shared data structures, and the like.
A large percentage of the driver code for simple device drivers, which consist primarily of calls to kernel interface routines, will change, but in straightforward ways. For complex device drivers (such as a SCSI driver) which contain large amounts of device-specific handling code, only a small percentage of the driver--the driver interfaces--changes. This driver interface can be a kernel-to-driver interface, a driver-to-kernel interface, or a driver-to-driver interface.
Before you determine how you will support a driver in the Solaris 2.6 operating environment, refamiliarize yourself with how the driver works. Determine what the SunOS release 4.x driver did (not the specific implementation, but general behavior). What interfaces did it export? What ioctl()s did it provide? How did the hardware work and what peculiarities of the hardware did the driver support? Did the driver support multiple open() calls?
The following changes affect drivers and should be considered:
The entry points to drivers are very different
Relocated or renamed header files (most, if not all, system header files are now in /usr/include/sys)
Some areas of change for STREAMS modules are transparent I/O controls, automatic pushing of modules on a stream, and new message types.
In the SunOS release 4.x software, you had to know that a particular driver was a STREAMS driver before making ioctl() requests.
For non-STREAMS drivers, you could do a direct ioctl() request:
ioctl(fd, DRIVER_IOCTL, arg); |
For a STREAMS driver, you had to set up a strioctl structure and then use:
ioctl(fd, I_STR, &strioctl); |
There was no easy way to determine whether a driver was STREAMS-based. Now, unrecognized ioctls to the stream head are passed on to the driver, eliminating the need to know whether a driver was STREAMS-based.
Message types added in the Solaris 2.6 software support transparent ioctls. There are now "copy in" and "copy out" messages to inform the STREAM head to transfer user data to and from the kernel.
For more information on writing STREAMS drivers, see the STREAMS Programming Guide.
The SunOS release 4.x streamtab structure enabled a driver to specify that certain STREAMS modules be pushed when the device was open().
In the Solaris 2.6 operating environment, the system administrator and the autopush(1M) command specify when a STREAMS module is pushed. If required, autopush can be run at driver installation.
See STREAMS Programming Guide for more information about pushing STREAMS modules.
To achieve binary compatibility across all currently supported hardware platforms, the DDI interfaces were carefully designed around architectural abstractions. The underlying abstraction, the device tree, is an extension of the devinfo tree in the original SPARCstation(TM) design. Each node in the device tree is described by a device information structure or "dev_info node." The bottom-most nodes in the tree are termed leaf nodes. Most devices (such as disks and tape drives, framebuffers, I/O cards, and network interfaces) are examples of leaf devices that would be associated with leaf nodes. The associated device drivers are called leaf drivers.
The intermediate nodes in the tree are generally associated with buses (for example, SBus, SCSI, VME). These nodes are called nexus nodes and the drivers associated with them are called nexus drivers. Bus nexi are intended to encapsulate the architectural details associated with a particular element.
Currently, the Solaris 2.6 DDI/DKI supports only the writing of leaf drivers and one type of nexus driver, the SCSI host bus adapter driver.
The device tree structure creates a formal parent-child relationship between nodes. This parent-child relationship is the key to platform architecture independence.
When a leaf driver requires a service that is platform dependent (for example, a DMA mapping), the system transparently converts the request into a call to its parent to provide the service. The service providers are always nexus drivers; each nexus driver can in turn pass the request to its parent in order to provide the service. This approach enables leaf drivers to operate regardless of the platform architecture.
The device driver commands are add_drv, rem_drv, modload, and modunload.