A.1 How to Use This Appendix

A feature of the SunDiag system exerciser is the ability to develop your own tests. If you're familiar with the C programming language, you can now use the libraries and routines in the /opt/SUNWdiag/lib and /opt/SUNWdiag/include directories to build your own SunDiag tests. You'll use these routines to communicate directly with the SunDiag kernel.

After you've created your own tests, refer to Section 1.9, "Adding Your Own Tests in .usertest," on page 1-17 to learn how to run your tests.

The header file sdrtns.h is in the /opt/SUNWdiag/include directory, and the library file libtest.a is in the /opt/SUNWdiag/lib directory. This Appendix is divided into the following sections:

Test Design Guidelines: general guidelines to think about when designing your tests	page A-2
Test Implementation Guidelines: description of the SunDiag programming environment, including global variables, special messaging facilities, and reserved error codes	page A-4
Requirements: five requirements you must meet to be compatible with the SunDiag kernel	page A-8

Standard Library Routines: detailed description of library routines	page A-11
Sample Test File	page A-17
Sample Makefile	page A-22

A.2 Test Design Guidelines

This section provides general guidelines to follow when developing your own SunDiag tests. You should try to incorporate most of these ideas when planning your tests. Most SunDiag tests already included in the /opt/SUNWdiag/bin directory adhere to these guidelines.

Options Each SunDiag test should have two main options -- a quick test mode, and a detailed step-by-step mode:

• The quick test mode for periodic system monitoring to ensure that the unit being tested is available and on-line. This mode has a requirement that, if the quick test option is set by the user, the test will run for a maximum of 30 seconds under normal system load.
• The step-by-step mode for detailed information in case the quick test fails to diagnose the device and provide service information.

For example, a quick test for a disk drive could be a read/write/compare test on the diagnostics cylinder. If the quick test fails, a sequence of sub-tests could be used to verify the path of the I/O device. Generally, all I/O devices under UNIX pass data through several stages before reaching the final destination. Build your test with these intermediate stages in mind, instead of using the standard, functional I/O route.

Error Messages The SunDiag environment provides special messaging facilities that allow your test to send information and error messages to log files or the console window, or to both. See "Special Messaging Facilities" on page A-6 for more information on how to account for these error messages.

Device Driver Support Since all SunDiag tests run under UNIX, hardware components and external devices are accessed through their associated device drivers. The purpose of the device driver is to provide a uniform interface to the application program, providing calls such as open(), read(), write(), and ioctl(). This design philosophy of device-independent programming in UNIX actually works against writing an on-line diagnostic program, since device-specific characteristics are "hidden" by the device driver. The "hooks" that can be implemented into the device driver are provided through the ioctl() calls. Base your test design not only on existing driver support, but also on possible ways of directly accessing the device through new ioctl() calls.

FRU Fault Isolation If a device can be partitioned into more than one FRU (Field Replaceable Unit), then organize your test so that each FRU can be tested separately.

Low Impact on System Performance Sometimes, it is desirable to design a test to exploit system resources to uncover any hidden stress/load failure conditions. But, the test should be able to co-exist with whatever applications are running and not interfere with most of those applications' activities.

Non-Intrusiveness If your test involves I/O, design the test so that it does not introduce any possibility for the system to lose or damage data. For example, if the test would need to write a data pattern on a type of media and read that pattern back for verification, make the test write to a diagnostic or maintenance area in the media, rather than to a normal, user-accessible area.

Utilization of Self-test Capability If a device to be tested has a built-in self-test capability, then use that self-test capability to gain more detailed information about a failure. Also, many device drivers provide the IOCTLDIAG ioctl() flag to find the error code for the last command issued to the device.

A.3 Test Implementation Guidelines

The purpose of defining SunDiag test implementation guidelines is to minimize, as much as possible, the restrictions and requirements placed on you when you develop new tests, without compromising the SunDiag system integrity or the test efficiency. In addition to detailing the SunDiag programming environment, SunDiag library routines included in /opt/SUNWdiag/lib are explained. Use these libraries so that you do not have to re-invent the basic programming environment each time you develop a new test.

A.3.1 The SunDiag Programming Environment

A.3.1.1 Global Variables

When users begin testing with SunDiag, they specify options from the OPEN LOOK user interface (which is, in fact, the SunDiag kernel.) These options are translated by the kernel into command line arguments (see "Standard Command Line Arguments" on page A-15) which are passed to individual tests, where the corresponding global variables will be set. It is the responsibility of each test to examine the state of these global variables and act accordingly.

Using these global variables insures consistent behavior in your tests. Table A-1 An Overview of SunDiag Global Variables

Read-Only Global Variables	Definition
int single_pass = FALSE;	TRUE, if single_pass enabled
int core_file = FALSE;	TRUE, if core_file to be created
int verbose = FALSE;	TRUE, if verbose mode enabled
int quick_test = FALSE;	TRUE, if quick_test enabled
int run_on_error = FALSE;	TRUE, if run_on_error enabled
int exec_by_sundiag = FALSE;	TRUE, if executed by Sundiag
int debug = FALSE;	TRUE, if debug mode is enabled
int trace = FALSE;	TRUE, if trace mode is enabled
int instances = n;	where n is the number of total instances for the test
int which_instance = n;	where n is the instance this test is assigned

Table A-1 (Continued)

Writeable Global Variables..........Description
You must set these four values in the tests you develop: char *versionid="unknown_version";..SCCS version id; printed in trace mode char *device_name="unknown_device"; name of UNIX device being tested char *func_name = "unknown_function"; function (routine) name; primarily used in trace mode int subtest_id = 999;..........subtest identification number, where you supply a value for a functional subtest within your test. See "Standard Formats Display" for this variable's usage.
Global Reserved Variables
The following are SunDiag reserved global variables and therefore should not be used: char *test_name; char *hostname; int list_usage = FALSE;........TRUE, if list_usage is enabled

int single_pass is set to FALSE by default; if a user specifies single_pass from the command line, then your test needs only to run one pass.

int core_file is flagged by the user to capture core files. If this flag is set to TRUE, the tests should not catch the signals. See signal() handling in the "Requirements" section of this appendix.

int verbose is set to TRUE when the user wants to see each test's functionality being traced.

int quick_test is set to TRUE for quick testing mode (a faster, abbreviated version of the test).

int run_on_error is set to TRUE by the user. If an error occurs, the test continues to run the next test sequence instead of exiting.

int exec_by_sundiag is set to TRUE if the test is executed by the SunDiag kernel, and FALSE if the test is executed from the command line.

int list_usage shows the user how to run the test. It provides three parts: command line usage, standard arguments, and routine-specific arguments.

int debug is set to TRUE if debugging mode is enabled.

int trace is set by the user to see the test's functionality traced down by function name in the console window.

char *func_name is a label used to indicate the name of the function within the test. It is used mainly in test trace mode to indicate which function the test is currently executing. This label is used as an argument in the debugging macros, TRACE_IN and TRACE_OUT.

instances = n is the number of total instances for the test.

which_instance = n is the instance this particular test is assigned.

char *versionid is a label used to indicate the SCCS version of the particular test. It is used to identify the version level of the test's source revision level. See "Standard Formats Display" on page A-16.

char *device_name is the name of the device being tested.

A.3.1.2 Special Messaging Facilities

The SunDiag software logs errors in a tiered manner using two log files. The first log file is the Info log file, where non-catastrophic errors are logged. The second log file is the Error log file, where more serious (catastrophic) errors are logged.

The SunDiag error-logging/message-handling routine send_message() (see "Standard Library Routines" on page A-11) recognizes the message types shown in Table A-2. They direct the error logger to send user-provided message to the proper log files.

---

Note - The #define statements are reserved and unique in the SunDiag exerciser, so you should not use the same define name for other purposes.

---

Table A-2

Define Name	ID #	Defined...
#define INFO	0	to info log only
#define WARNING	1	to info log only
#define FATAL	2	to info and error logs
#define ERROR	3	to info and error logs
#define LOGFILE	4	1 to info log (unformatted)
#define CONSOLE	5	to SunDiag console (unformatted)
#define VERBOSE	6	same as CONSOLE, but formatted in SunDiag mode, unformatted in on-line command mode
#define DEBUG	7	same as VERBOSE
#define TRACE	8	to console with trace format

1. The format is described in "Standard Formats Display" later in this appendix.

---

Note - You should not use printf() or fprintf() in your test code to display messages or information. Instead, use send_message() with one of the message types defined in Table A-2.

---

VERBOSE lets general SunDiag users understand how testing is progressing. When VERBOSE mode is enabled by the user, test and subtest messages are printed to the console window while testing is conducted.

DEBUG gives test programmers or sophisticated users more detail or internal information about the tests they are developing. This type of information may include a data structure snapshot, data buffer contents, more detailed procedures, or even describe a changed variable value that could be important for debugging.

TRACE lets users understand the test code structure and the procedures the test goes through. More importantly, TRACE can tell a developer at what function scope level the system hangs.

VERBOSE and DEBUG messages are not associated; they don't control or supervise each other.

For the sake of standardization, the SunDiag console window always displays "formatted" messages for all the message types except CONSOLE and LOGFILE. However, for testing in the on-line command mode, all messages are displayed "unformatted." TRACE messages are somewhat different, but they should be self-explanatory to the user. Note that there is one special message type, VERBOSE+DEBUG or DEBUG+VERBOSE, that allows the specified message to be displayed while either the VERBOSE or DEBUG flag is enabled.

A.3.1.3 Reserved Exit Codes

Table A-3 shows a reserved exit code used by send_message(). You can define your own exit codes; however, the SunDiag reserved exit code should not be changed.

Table A-3 send_message()

Define Name	ID #	Definition
#define SKIP_ERROR	0	skip error, continue testing

The exit codes -1 and 90-99 are SunDiag reserved exit codes and therefore should not be used.

A.4 Requirements

Now that you know the basic structure of the SunDiag programming environment, you'll need to follow these five requirements.

1. Use the standard routine send_message() for error or message handling.

The standard routine send_message() has only two categories of exit status: zero (SKIP_ERROR), and nonzero (ERROR). Use the nonzero status, message type, and string for SunDiag logging errors and program exit. If some error is minor and tolerable, and the program needs to continue after error logging, use SKIP_ERROR in send_message().

Do not use the printf() type of macro, since stdout is redirected to the SunDiag console window.

To write a message to the SunDiagLog use send_message() with ret_status zero (SKIP_ERROR); the program will continue to the next line of code after send_message() returns.

Always use send_message(), instead of printf(), to report text messages as follows:

send_message(SKIP_ERROR, VERBOSE, "....%s..%d", par1, par2);

or

send_message(0, DEBUG, "......");

or

send_message(0, DEBUG+VERBOSE, "....%d..%s", par1, par2);

---

Note - The current version of send_message() is capable of handling variable arguments, just like printf() does. Often, it's useful to print the error message after a system call error. Just pass strerror(errnum) as the third argument to send_message().

---

2. Always use the proper exit code for terminating tests.

For the normal non-error termination, the test code should use exit(0) at the end. Do not use error codes -1 and 90-99, since they are reserved SunDiag exit codes.

3. Define device_name in your test code.

send_message() uses the global variable device_name to pass the current device name to the server for error logging. This variable has to be set with the proper string values at the earliest phase. For example:

main(argc, argv) int argc; char *argv[]; { device_name = "/dev/rsd0" ... }

Code Example A-1 Defining device_name

In this example, the device_name is set to a fixed device string name at the beginning of the main routine.

However, for some complicated tests that may go through several devices in one test, you might want to assign a string pointer variable to device_name. But beware; avoid using the statement:

strcpy (device_name, "/dev/llllllonggggggnnnname")

or

  strcpy (device_name, device_string);

since device_name, from your viewpoint, is just defined as:

  extern char *device_name;

indicating no known adequate space allocated to this pointer.

4. Always provide clean_up() in your test code.

clean_up() is a routine that is called by the SunDiag library routine finish(), which will be called by the signal() handler described below. This routine allows you to return the programming environment to the state it was before running the test. You'll need to write your own clean_up().

For example, if you disabled the mouse pointer during your test, this is the routine where you would re-enable the mouse pointer.

5. signal() Handling

One of the functions of the SunDiag library routine test_init() is to catch signal() for the SIGHUP, SIGTERM, and SIGINT signals. When any of the above signals are detected, a call is made to the SunDiag library routine finish(), which, in turn, calls your test routine clean_up(), and then the test will exit.

If you want to use your own signal-catching mechanism, you must remap the signal vector in your test code. This can be done by calling signal() after calling test_init().

A.5 Standard Library Routines

The SunDiag program provides some standard routines for communication with each test. You should use these routines in your test to communicate with the SunDiag kernel.

1. void send_message(exit_code, type, format[, arg]...)

   This routine is used for SunDiag message handling. It has three required arguments:

   int exit_code: If this argument is zero (SKIP_ERROR), send_message() logs the error message and returns to its caller; if non-zero, it calls your clean_up() routine and exits with exit_code. The exit_code will also become the "message identifier" in the logged message. See Section A.5.2, "Standard Formats Display" for details.

   int type: Indicates message type based on its error status or severity (for example, ERROR, WARNING or INFO).

   char *format: This argument uses the same format as printf(). This defines the number of arguments that will follow. The message provided here will be formatted by the SunDiag program if its msg_type is VERBOSE, INFO, WARNING, FATAL, or ERROR; otherwise, the message will appear unformatted.

---

Note - If the exec_by_sundiag flag is not set, send_message() will redirect all output to stderr, thus allowing the test to be executed from the UNIX shell command line.

---

2. void test_init(argc, argv, process_test_args, routine_usage, test_usage_msg)

   This routine simplifies the procedures required by SunDiag for each test code. It combines almost all the necessary test initialization procedures required by SunDiag into one routine.

   This routine requires five arguments:

   int argc: UNIX standard input arguments

   char *argv[]: UNIX standard input arguments

   int (*process_test_args)(argv, argindex): This argument is a pointer to a function that processes test-specific command line arguments. This function is invoked once for each

command line argument process by test_init(), and it requires two arguments: char *argv[], and int argindex, where argindex is an index for the argv[] array.

For SunDiag naming conventions, the test portion of the routine name is usually replaced by "test". For example, in the disk test, the name is

   process_scsidisk_args().
   int (*routine_usage)():
   This argument is a pointer to a function that displays explanations of the
   test-specific command arguments.
   char *test_usage_msg:
   This is a pointer to a string that contains the general usage of the test
   command. For example, if the test uses a device "foo," then the
   test_usage_message might say something like:
   testname D=foo

test_init takes care of the following test initialization procedures:

• Gets test_name from argv[0].
• Sets up the signals SIGHUP, SIGTERM, and SIGINIT, and links them to the SunDiag library finish() routine.
• Checks and processes the SunDiag standard command line arguments.
• Checks and processes test-specific arguments by calling the user-provided process_args routine, which gives you some flexibility to check and manage your own test-specific arguments.
• Checks the existence of any test_usage_msg for test-specific arguments. This argument allows the user to type the test name to run in an on-line command mode if no test_usage_msg is required.
• Displays a user-provided test_usage_msg if an argument check error occurs.
• Displays test usage by invoking the user-provided routine_usage() routine when the 'u' (usage) argument is detected at command line parsing.
• If the global variable core_file is set to TRUE, sets up the signals SIGILL, SIGBUS, and SIGSEGV to link with the SunDiag library exception() routine to avoid core dumps.
• If the verbose flag is set to TRUE, displays the verbose message "Started" to show a test has started executing.

3. void test_end()

   This routine works in tandem with test_init() to do the following:

• Display the verbose message "Stopped" as indication of end of testing
• Exit with exit(0).

You should use test_init() and test_end() to start and end your SunDiag test code, since they simplify your test code structure. Using test_init() and test_end() also ensures compatibility with future, enhanced versions of SunDiag software.

4. void trace_before(string)

   This routine attaches the user-provided string to the end of the trace format message. It traces down the control flow of the testing program by displaying the function names being called and their scope level relative to the program's main routine (L0).

   This routine takes one argument:

   char *string: The string argument is any user-supplied string value.

   This routine derives one macro, called TRACE_IN, that is often used in SunDiag test code. TRACE_IN is defined in sdrtns.h as

     (void)trace_before((char *)NULL)

  which is also equivalent to

     (void)trace_before(func_name).

You may want to put a trace_before() call before you enter some routine
that may be suspected:

trace_before("entering suspect routine") suspect_routine() trace_after("exited out of suspect_routine")

Code Example A-2 Using trace_before and trace_after to bracket suspect function calls

5. void trace_after(string)

   This routine works in conjunction with trace_before(). Use trace_before() prior to entering one area, then use trace_after() after leaving that area. As in trace_before(), a macro called TRACE_OUT is defined in sdrtns.h as

(void)trace_out((char *)NULL)

To properly write a SunDiag test, you should use the TRACE_IN and TRACE_OUT macros for each function to complete the trace mode of your test:

function() { func_name = "function"; TRACE_IN ... ... TRACE_OUT return(0) }

Code Example A-3 Using the TRACE_IN and TRACE_OUT macros to bracket each function in your test. Remember that "func_name" is a library defined global variable.

A.5.1 Standard Command Line Arguments

Every SunDiag test should be able to handle the command arguments shown in Table A-4.

Table A-4

Command Line Argument	1 Global Variables
s, sundiag mode	exec_by_sundiag
c, enable core dump	file_core_file
p, single pass only	single_pass
r, run on error	run_on_error
q, quick test	quick_test
u, list usage	list_usage
v, verbose mode	verbose
d, debug mode	debug
t, trace mode	trace
i = n, where n is the number of total instances for the test	instances = n
w = n, where n is the instance this test is assigned	which_instance = n

1. The variable will be set to TRUE if the option was specified in the command line and after test_init() was called.

For more details about each command line argument function, see Chapter 5, "Running Individual SunDiag Tests from the Command Line." For the global variable associated with these command line arguments, see the section "Global Variables" on page A-4 of this appendix.

A.5.2 Standard Formats Display

Messages that appear in info log files or error log files are formatted in the following way:

999.VV.SSS.EEE date time device test [ERROR/FATAL/INFO/WARNING]: message

where:

999 = test identifier (three digits) signifies "user-defined" tests

VV = test version identifier (two digits) uses "versionid" variable

SSS = subtest identifier (three digits) uses "subtest_id" variable

EEEE = error identifier. The first digit is the priority identifier (message type) and the other three digits are the message identifier. See Table 2-1 for the definition of the priority identifier.

For more information, see "Log Files Window Button" on page 2-11.

A.5.2.1 Trace Mode Formats

The formats for trace mode display are the following:

For on-line command mode:

  @test device: L# func_name(Enter) string (for TRACE_IN)

  @test device: L# func_name(Leave) string (for TRACE_OUT)

where L# indicates the scope level of the function func_name in the test code relative to the main scope level (L0).

For SunDiag window mode:

date time device test: L# func_name(Enter) string (for
TRACE_IN)

date time device test: L# func_name(Leave) string (for
TRACE_OUT)

A.6 A Sample Test File

You can use the following sample test file as a template for developing your own SunDiag test.

Code Example A-4 Sample SunDiag Test (1 of 5)

"@(#)newtest.c 1.11 90/01/05 Copyright Sun Micro". #ifndef lint static char sccsid[] = "%Z%%M% %I% %E% Copyright Sun Micro"; #endif #include <stdio.h> #include "newtest_msg.h" #include "sdrtns.h"/* sdrtns.h should always be included */ #define DEVICE_NAME "newdevice" #define TOTAL_PASS 7/* number of test loops */ #define ERROR_LIMIT 5/* max number of errors allowed if run_on_error */ /* error return code definitions(can be put in a.h file) */ #define NEWTEST_ERROR 1 #define TOO_MANY_ERRORS 2 static char *test_usage_msg = "[test_specific_cmd1] [test_specific_cmd2]"; static int flag1, flag2; /* * This is a test template for SunDiag, and is intended to show how you * should write a test to be run by SunDiag. * * First, get the command-line arguments, then validate and/or assign the device * name, probe for the device, and then run the test(s). The verify mode is * not currently used by SunDiag, but may be useful for running the test by * itself under Unix. Note that the average test should run from three to * five minutes, and the TOTAL_PASS symbolic constant can be adjusted to * generate proper testing period. * * Note: When run by SunDiag, stdout and stderr will be redirected to SunDiag's * console window. stdin is disabled. */ main(argc, argv) int argc; char *argv[]; { extern int process_test_args();

Code Example A-4 Sample SunDiag Test (2 of 5)

extern int routine_usage(); versionid = "%I%"; /* device_name can be fixed or passed in from command line */ device_name = DEVICE_NAME;/* fixed in this case */ /* Always start with test_init to enter SunDiag environment */ test_init(argc, argv, process_test_args, routine_usage, test_usage_msg); if (!exec_by_sundiag) { valid_dev_name(); probe_newdev(); } run_tests(single_pass ? 1 : TOTAL_PASS); /* pass the desired loop count and do real testing from here */ clean_up(); /* Always end with test_end to close up SunDiag environment */ test_end(); } /* * Process_test_args() processes test-specific command line arguments. */ process_test_args(argv, argindex) char *argv[]; int argindex; { if (strcmp(argv[argindex], "test_specific_command_1") == 0) flag1 = TRUE; else if (strcmp(argv[argindex], "test_specific_command_2") == 0) flag2 = TRUE; else return FALSE; return TRUE; } /* * routine_usage() explain the meaning of each test-specific command * argument. */

Code Example A-4 Sample SunDiag Test (3 of 5)

routine_usage() { send_message(0, CONSOLE, "%s specific arguments [defaults]:\n\ test_specific_cmd1 = meaning of command 1\n\ test_specific_cmd2 = meaning of command 2\n", test_name); } /* * You may also want to consider validating the device name, if your test is * also to be run standalone (i.e., without SunDiag) under Unix. */ valid_dev_name() { func_name = "valid_dev_name"; TRACE_IN TRACE_OUT return (0); } /* * The probing function should check that the specified device is available * to be tested(optional if run by Sundiag). Usually, this involves opening * the device file, and using an appropriate ioctl to check the status of the * device, and then closing the device file. There are several flavors of * ioctls: see dkio(4s), fbio(4s), if(4n), mtio(4), and so on. It is nice to * put the probe code into a separate code module, because it usually has * most of the code which needs to be changed for a new SunOS release or * port. */ probe_newdev() { func_name = "probe_newdev"; TRACE_IN TRACE_OUT return (0); } /* * Run the test while pass < total_pass. * * Re: send_message, there are 3 variables for send_message(exit_code, type, * msg). "exit_code" indicates the type of error(such as TOO_MANY_ERRORS). A * non-zero exit_code will force send_message to terminate the test and use

Code Example A-4 Sample SunDiag Test (4 of 5)

* it as exit code. Ret_code 97-99 are reserved by SunDiag for * RPCFAILED_RETURN(97), INTERRUPT_RETURN(98), and EXCEPTION_RETURN(99). For * "type", use INFO, WARNING, FATAL, ERROR, LOGFILE, or CONSOLE. For "msg", * use a pointer (char *) to a message buffer. * * send_message() always writes the "msg" to stderr, and if run by SunDiag, it * will also log "msg" to INFO log and ERROR log (for msg_type FATAL and * ERROR). * * The "msg" is formatted as follows before written: (void)sprintf(msg_buf, * "%02d/%02d/%02d %02d:%02d:%02d %s %s %s: %s\n", (tp->tm_mon + 1), * tp->tm_mday, tp->tm_year, tp->tm_hour, tp->tm_min, tp->tm_sec, * device_name, test_name, msg_type, msg); * * For more details, read sdrtns.c and sdrtns.h. */ run_tests(total_pass) int total_pass; { int pass = 0; int errors = 0; func_name = "run_tests"; TRACE_IN while (++pass <= total_pass) { send_message(0, VERBOSE, "Pass= %d, Error= %d", pass, errors); if (!newdev_test()) if (!run_on_error) send_message(NEWTEST_ERROR, ERROR, failed_msg); else if (++errors >= ERROR_LIMIT) send_message(TOO_MANY_ERRORS, FATAL, err_limit_msg); } TRACE_OUT } /* * The actual test. Return True if the test passed, otherwise FALSE. * * Note: the "quick_test" flag is used to force an error here. Its normal use is * to force a "quick(short)" version of the test. */

Code Example A-4 Sample SunDiag Test (5 of 5)

int newdev_test() { func_name = "newdev_test"; TRACE_IN TRACE_OUT return (quick_test ? FALSE : TRUE); } /* * clean_up(), contains necessary code to clean up resources before exiting. * Note: this function is always required in order to link with libtest.a * successfully. */ clean_up() { func_name = "clean_up"; TRACE_IN TRACE_OUT return (0); }

A.7 A Sample Makefile

The following Makefile is a general example of what happens when you "make" your SunDiag test code.

Code Example A-5 Sample SunDiag Makefile (1 of 2)

# # @(#)Makefile 1.12 90/01/05 Copyright(c) Sun Microsystems, Inc. # .DEFAULT: sccs get -G$@ $@ DBX=-O # specify DBX=-g for dbx version DESTDIR = PROGRAM = newtest INCLUDES= newtest_msg.h sdrtns.h LIBS = SOURCES = newtest.c newtest_msg.c OBJECTS = $(SOURCES:.c=.o) LINTFILES = $(SOURCES:.c=.ln) CFLAGS = $(DBX) -D$(REV) -D`arch` LDFLAGS = $(DBX) LINTFLAGS= -D$(REV) -D`arch` .KEEP_STATE: ##### beginning of dependency lines ##### all: $(INCLUDES) $(PROGRAM) $(PROGRAM): $(OBJECTS) cc $(LDFLAGS) -o $@ $(OBJECTS) $(LIBS) install: all FRC @if [ $(DESTDIR) ]; then \ set -x; \ install -s $(PROGRAM) $(DESTDIR); \ else \ set -x; \ install $(PROGRAM) ../../bin; \ fi

Code Example A-5 Sample SunDiag Makefile (2 of 2)

clean: FRC rm -f $(PROGRAM) $(OBJECTS) $(LINTFILES) core lint: $(LINTFILES) lint $(LINTFLAGS) $(LINTFILES) $(LIBS) info: FRC sccs info