For the past few years, Sun engineering has been hard at work making the x86
platform a first-class citizen. In case you've been napping, some of the
highlights included:
The SMBIOS image consists of a table of structures, each describing some aspect of the system software or hardware configuration. The content of the image varies widely by platform and BIOS vendor, and may not exist at all on some systems. However, it is the only known mechanism for system software to obtain certain information on x86 systems. A simple example of information found in SMBIOS is the actual name of the platform (e.g. Sun Microsystems v40z), the BIOS vendor, version, and release date. More advanced records describe the DIMM slots in the machine, their labels (i.e. how you can locate them if you crack open the case), and various other slot types and properties.
Not much attention has been paid to SMBIOS: Windows uses it to get the system serial number and is beginning to emphasize its importance to hardware vendors, and the Linux dmidecode utility (DMI was the original name of the SMBIOS spec) has been available for some time to dump it all out in human-readable form for hackers and administrators who wish to peek at some of the details of the underlying hardware on their platform.
The initial SMBIOS support provides the following new features:
Here is the usage for the new smbios(1M) utility:
And here is some output from the x86 prtdiag using SMBIOS:
For example, in Solaris, we have an incredibly flexible virtual memory allocator built out of two layers, vmem and kmem. The introduction of vmem in Solaris 8 allowed us to delete about 50 special-purpose non-scalable memory allocation subsystems in Solaris, greating simplifying the kernel, while at the same time improving the scability, performance, and debuggability of all those new clients. That's leverage.
File and data formats are another place where investing in a high-leverage subsystem is really worthwhile. The leverage points I wanted for SMBIOS were:
Here is a diagram of the new subsytem, showing the source code, binaries, and how the layering works:
The source code in /usr/src/common/smbios/ contains the code to initialize an SMBIOS snapshot from a file or in-memory buffer, and provide a set of common programming APIs for consuming software. This code is compiled twice: once to form an in-kernel SMBIOS subsystem, and a second time to form the bulk of the userland libsmbios library. The library and kernel each provide a small set of glue routines in a file named smb_subr.c, and then each provide some basic discovery routines. For the kernel, discovery is performed by mapping the BIOS's physical memory region and scanning for the SMBIOS table. For the userland library, discovery is performed either by opening a file or a device, or scanning a device which exports the BIOS's physical memory region.
The kernel then implements a small pseudo-driver, smbios(7D), which simply takes the SMBIOS data discovered at boot time and exports it for use by the library. In userland, the smbios(1M) utility provides generic data display for developers, and an x86 prtdiag is provided which also leverages the library. In the kernel, the IPMI bmc(7D) driver uses the in-kernel subsystem to discover the local Baseboard Management Controller, for use with ipmitool. As you might expect, the original IPMI driver implementation had its own private, buggy, non-leveraged SMBIOS decoder, and all that just got deleted.
One final trick to achieve maintainability is that I wrote a shell script that auto-generates C source to convert the integers used in various SMBIOS fields into the corresponding human-readable strings by simply grabbing the comments next to the appropriate #defines in the new smbios.h. As such, there's no way that a developer can add or modify our definition of the format and forget to update the smbios(1M) output.
You can find out more about Fault Management in Solaris from our OpenSolaris community or by posting a question to the discussion forum. If you're interested in looking at the source code or experimenting with the interfaces, you can use the OpenSolaris Source Browser to locate things. It will take a week or so for the code to propagate into the Source Browser's snapshot of the OpenSolaris tree.
$q
Technorati Tag: OpenSolaris
Technorati Tag: FMA
- the release of Solaris 10 with complete support for the x64 architecture,
- a deal with AMD that has led to engineering partnership and some great new x64 platforms,
- world-record benchmarks using Solaris 10 on those x64 systems, and
- the release of OpenSolaris, making our source code freely available to all developers.
- fast, simple GRUB-based booting, replacing our antiquated x86 boot mechanism from previous Solaris releases,
- a complete upgrade of our ACPI stack to the latest Intel code, and
- support for Xen, the OpenSource virtualization project.
What is SMBIOS?
System Management BIOS (SMBIOS) is a data structure exported by most modern BIOSes on x86 platforms, including those currently produced by Sun. SMBIOS is an industry-standard mechanism for low-level system software to export hardware configuration information to higher-level system management software. The SMBIOS data format itself is defined by the Distributed Management Task Force (DMTF). Refer to dmtf.org if you want to read a copy of the specification itself.The SMBIOS image consists of a table of structures, each describing some aspect of the system software or hardware configuration. The content of the image varies widely by platform and BIOS vendor, and may not exist at all on some systems. However, it is the only known mechanism for system software to obtain certain information on x86 systems. A simple example of information found in SMBIOS is the actual name of the platform (e.g. Sun Microsystems v40z), the BIOS vendor, version, and release date. More advanced records describe the DIMM slots in the machine, their labels (i.e. how you can locate them if you crack open the case), and various other slot types and properties.
Not much attention has been paid to SMBIOS: Windows uses it to get the system serial number and is beginning to emphasize its importance to hardware vendors, and the Linux dmidecode utility (DMI was the original name of the SMBIOS spec) has been available for some time to dump it all out in human-readable form for hackers and administrators who wish to peek at some of the details of the underlying hardware on their platform.
SMBIOS and Solaris
The work I integrated this weekend into Solaris provides an equivalent decoding utility for SMBIOS (albeit with some nicer features), but is actually a stepping stone to connecting this information with the new Fault Management features we introduced in Solaris 10. As such, I wanted to provide a much richer environment for dealing with SMBIOS. Specifically, we're working on the first collection of Fault Management features for x64 right now, part of our broader effort to implement Predictive Self-Healing in Solaris. For x64 platforms, the first set of features will include automated diagnosis and fault isolation for Opteron CPU and Memory errors and for our PCI-E stack, all connected to our standardized self-healing administration model, messaging, and knowledge article web. SMBIOS is a tiny piece of this puzzle: it gives us the ability to label self-healing diagnosis messages with the appropriate chassis serial number you need to provide if you file a service call, and allows us to properly identify faulty FRUs you need to replace with the labels that will let you easily locate and remove them from your box.The initial SMBIOS support provides the following new features:
- A common set of Solaris APIs to decode and examine SMBIOS images. The
common source is compiled both into a new user library, libsmbios, and
into the kernel itself. The APIs provide a simplified programming model for
accessing SMBIOS, converting the string table indices to string pointers,
sanitizing addresses, and generally handling all the bizarre implementation
artifacts of the data format itself.
- A new smbios(1M) utility to permit developers and administrators
to examine SMBIOS images either exported by the system or stored in a file
on disk. You can also copy your SMBIOS image out to a file (this might be
useful for building a catalog of machine configurations, and was very useful
to me in developing automated test software for this whole thing).
- A new smbios(7D) character special device that exports a snapshot
of the current system's SMBIOS image, taken at the time the system boots.
- An implementation of prtdiag(1M) (long present on SPARC Solaris) for Solaris x86 platforms that displays the x86 platform name and summary hardware information using SMBIOS.
Here is the usage for the new smbios(1M) utility:
Usage: smbios [-BeOsx] [-i id] [-t type] [-w file] [file]
-B disable header validation for broken BIOSes
-e display SMBIOS entry point information
-i display only the specified structure
-O display obsolete structure types
-s display only a summary of structure identifiers and types
-t display only the specified structure type
-w write the raw data to the specified file
-x display raw data for structures
And here is some output from the x86 prtdiag using SMBIOS:
System Configuration: Sun Microsystems W1100z/2100z BIOS Configuration: Sun Microsystems R01-B2 S0 10/12/2004 ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- AMD Opteron(tm) CPU1 AMD Opteron(tm) CPU2 ==== Memory Device Sockets ================================ Type Status Set Device Locator Bank Locator ------- ------ --- ------------------- -------------------- DDR empty 1 DIMM1 Bank 0 DDR empty 1 DIMM2 Bank 0 DDR in use 2 DIMM3 Bank 1 DDR in use 2 DIMM4 Bank 1 DDR empty 5 DIMM5 Bank 2 DDR empty 5 DIMM6 Bank 2 DDR in use 6 DIMM7 Bank 3 DDR in use 6 DIMM8 Bank 3 ==== On-Board Devices ===================================== ==== Upgradeable Slots ==================================== ID Status Type Description --- --------- ---------------- ---------------------------- 0 unknown AGP 8X AGP8X PRO 110 1 available PCI-X PCIX1-100MHZ 0 unknown PCI-X PCIX2-133MHZ 3 available PCI-X PCIX3 100 ZCR 0 unknown PCI-X PCIX4 100 0 unknown PCI-X PCIX5 100
SMBIOS Subsystem Design
One of the most important principles in system software design (or really any large-scale software effort) is what I refer to as leverage, which is my shorthand for locating high-leverage subsystems that form the basic building blocks of the system, and really engineering these things right such that a wide variety of consumers can be easily and flexibly built on top.For example, in Solaris, we have an incredibly flexible virtual memory allocator built out of two layers, vmem and kmem. The introduction of vmem in Solaris 8 allowed us to delete about 50 special-purpose non-scalable memory allocation subsystems in Solaris, greating simplifying the kernel, while at the same time improving the scability, performance, and debuggability of all those new clients. That's leverage.
File and data formats are another place where investing in a high-leverage subsystem is really worthwhile. The leverage points I wanted for SMBIOS were:
- common API for both userland and kernel consumers built from same source code
- ability to access SMBIOS from file, memory buffer, or pseudo-device
- ability to easily maintain and extend the human-readable decoding
Here is a diagram of the new subsytem, showing the source code, binaries, and how the layering works:
The source code in /usr/src/common/smbios/ contains the code to initialize an SMBIOS snapshot from a file or in-memory buffer, and provide a set of common programming APIs for consuming software. This code is compiled twice: once to form an in-kernel SMBIOS subsystem, and a second time to form the bulk of the userland libsmbios library. The library and kernel each provide a small set of glue routines in a file named smb_subr.c, and then each provide some basic discovery routines. For the kernel, discovery is performed by mapping the BIOS's physical memory region and scanning for the SMBIOS table. For the userland library, discovery is performed either by opening a file or a device, or scanning a device which exports the BIOS's physical memory region.
The kernel then implements a small pseudo-driver, smbios(7D), which simply takes the SMBIOS data discovered at boot time and exports it for use by the library. In userland, the smbios(1M) utility provides generic data display for developers, and an x86 prtdiag is provided which also leverages the library. In the kernel, the IPMI bmc(7D) driver uses the in-kernel subsystem to discover the local Baseboard Management Controller, for use with ipmitool. As you might expect, the original IPMI driver implementation had its own private, buggy, non-leveraged SMBIOS decoder, and all that just got deleted.
One final trick to achieve maintainability is that I wrote a shell script that auto-generates C source to convert the integers used in various SMBIOS fields into the corresponding human-readable strings by simply grabbing the comments next to the appropriate #defines in the new smbios.h. As such, there's no way that a developer can add or modify our definition of the format and forget to update the smbios(1M) output.
You can find out more about Fault Management in Solaris from our OpenSolaris community or by posting a question to the discussion forum. If you're interested in looking at the source code or experimenting with the interfaces, you can use the OpenSolaris Source Browser to locate things. It will take a week or so for the code to propagate into the Source Browser's snapshot of the OpenSolaris tree.
$q
Technorati Tag: OpenSolaris
Technorati Tag: FMA