The utsname macro

We've already seen one macro in use on a Solaris 2 system, utsname . As a refresher, here is how we called the utsname macro while in adb analyzing postmortem files. Note that this macro is not given a specific address with which to work.

Figure 12-1 Using the utsname macro

 Hiya...  adb -k unix.1 vmcore.1  physmem 1b24  $<utsname  utsname:  utsname:        sys  SunOS  utsname+0x101:  node  panic  utsname+0x202:  release  5.3  utsname+0x303:  version  Generic  utsname+0x404:  machine  sun4c  $q  Hiya...

In adb , $< says to bring in or execute a macro, in this case the utsname macro. If you like, think of this as being like UNIX I/O redirection. Unless we specify a full pathname, adb assumes we want to work with the utsname macro file stored in the /usr/kvm/lib/adb directory.

Let's take a look at /usr/kvm/lib/adb/utsname .

Example 12-1 The utsname macro

 Hiya...  cd /usr/kvm/lib/adb  Hiya...  more utsname  utsname/"sys"8t257c  +/"node"8t257c  +/"release"8t257c  +/"version"8t257c  +/"machine"8t257c  Hiya...

The first thing this macro does is change our current location within adb to where the variable utsname is stored. The text "sys" is printed solely for the user 's sake, helping him to understand what is being output. The 8t says to tab out to the nearest tab stop located at a column that is a multiple of 8, then display up to 257 printable characters .

Now we move on to the next line of the utsname macro. We use + to advance our current location according to the previous display format we used. We print "node", tab out for readability, and display up to another 257 characters.

Continuing to the last three lines, we repeat this whole process for "release" , "version" , and "machine" .

Now, how do we know what this macro is showing us? Well, if we poke around in the /usr/include/sys directory, we will find a header file called utsname.h . (Isn't that convenient ? Don't count on such ease all of the time!) Within utsname.h we find the following information, although it is not all clustered together as shown below.

Example 12-2 Excerpts from /usr/include/sys/utsname.h

 #define _SYS_NMLN       257    /* 4.0 size of utsname elements */                                 /* Must be at least 257 to      */                                 /* support Internet hostnames.  */  struct utsname {       char    sysname[_SYS_NMLN];        char    nodename[_SYS_NMLN];        char    release[_SYS_NMLN];        char    version[_SYS_NMLN];         char    machine[_SYS_NMLN];  };  extern struct utsname utsname;

Using what we have learned so far, we can see in /usr/include/sys/utsname.h that utsname is the name given to a type of defined structure. The five elements of this structure contain character strings of _SYS_NMLN or 257 decimal in length. Finally, we see that the utsname structure was used elsewhere (extern) to declare a structure variable, also called utsname . In this case, to see this structure's definition, we would have to look at the source. However, as we have seen by using the utsname macro, it is quite safe to assume that the declared utsname structure contains the system information we would expect to see there.

If you don't happen to have a set of system crash dump files to experiment with at this time and you want to look at the utsname structure on your own Solaris 2 system, go ahead and run adb on the running kernel. To do this, you will need to be root. As an example, here is an adb session that looks at an actively running system.

 Hiya...  su  Password:  #  adb -k /dev/ksyms /dev/mem  physmem 1e15  $<utsname  utsname:  utsname:        sys     SunOS  utsname+0x101:  node    pasta  utsname+0x202:  release 5.3  utsname+0x303:  version Generic_Patch  utsname+0x404:  machine sun4c  $q  #

Let's take a look at another relatively simple macro from the /usr/kvm/lib/adb directory on a Solaris 2 system and figure out what it does.