Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Next Generation BMC Driver 1.2. Name of Document Author/Supplier: Author: Barry Harding 1.3 Date of This Document: 30 June, 2010 4. Technical Description 4.1. Project Summary: This project provides a replacement to the existing BMC driver. The existing driver supplies access to a systems baseboard management controller. It supplies this access using IPMI (Intelligent Platform Management Controller) protocol. The replacement driver will supply an extensible software model that supports both our existing proprietary BMC API and an industry accepted open API. 4.2. Type of release: Minor 4.3. Project Details: This project is divided into two phases. The first phase implements the OpenIPMI driver and the BMC shim module. Also the primary back-end plug-ins are implemented but are configured and compiled into the main driver module. Only one plug-in may be active at a time and this is only done at main driver load time. (see details below) In the second phase, which is optional, the plug-ins are separated into discrete modules. A way to configure more then one active plug-in at a time is added. Plug-ins could get added at any time during or after driver load. Also in the second phase, the old BMC API and the shim module will get EOL'd. Last we could possibly make the plug-in interface public. Phase One, more details: Now the biggest technical reason for this work. Our BMC driver only supports basic IPMI functionality while the open ones supports a much fuller set of features. The architecture of the existing driver forces some of these limits to the feature set because of its use of STREAMS. On top of that the BMC user-land API's are poorly designed, forcing the application to deal with the STREAMS based nature of the existing driver. In fact STREAMS is one of the big technical reasons to replace the existing driver! The nature of the IPMI hardware with IPMI protocol directly conflicts with the STREAMS framework constraints. This makes this driver more complicated then it needs to be and has been the main source for problems with this driver for years. All that with no benefits of using STREAMS in this driver. There are two parts to this phase. One part is a new driver that fully supports the OpenIPMI API. This new driver is a character based driver. The other part is a separate module which supplies the older BMC API and acts as a BMC to Open driver shim. Ideally it would be good to leverage an existing (non GNU) open driver (BSD version most likely) which is already OpenIPMI compliant. The goal is to port an OpenIPMI driver and continue to get updates of the open driver as needed. The BMC to Open driver shim will be made from the front-end of the existing BMC driver. It will use LDI kernel services to open the new OpenIPMI driver and use the same API that user-land applications would use to access BMC/IPMI services. The following is an overly simplified picture of this design: | Sun BMC ipmi app | | OpenIPMI app | ------------------ ------------------ | (/dev/bmc) | (/dev/ipmi) | User-Land | =========================================================== | | |-------------------| | | Stripped out BMC | | | used as shim to | | | OpenIPMI driver | | |(old streams code) | | ------------------- | | | | (ldi kernel driver | (character driver) | interface) | ----------------------------------| | --------------------------------------------- | BSD OpenIPMI Driver | --------------------------------------------- | -----------------------~~ (Future driver modules) plug-in interface | Proposed configurable driver back-end | | -------------------- --------------------------- | BMC serial code | | OpenIPMI direct plug-in | -------------------- --------------------------- | | ~ ~ (ldi kernel interface ~ VLDC to serial driver) (BMC KCS Hardware) The OpenIPMI driver does not act as a nexus for the back-end plug-in. But each plug-in supplies a list of access methods that are used as the main point of communications between the plug-in and the main driver. These methods supply several types of accesses. One, request/response IPMI message movement. Two, asynchronous event signaling (both directions). Three, initialization and configuration operations. Lastly error handling. The main driver does not reference or depend on the plug-ins directly. The plug-ins however depend on the main driver. In fact each plug-in has one direct reference to a function in the main driver which is used to register a plug-in with the driver. Note also that each plug-in may or may not be a separate module. Also only one plug-in can be active at a time for the first version of this driver (but that can change in the future if needed). The following is an overly simplified list of steps to get plug-ins connected to the main driver: 1.) plug-in loads. 2.) In early plug-in initialization plug-in supplies partially filled in method structure to main driver. 3.) plug-in calls main driver register routine with method structure. 4.) main driver fills in rest of method structure. 5.) at some later point main driver probes plug-in via method to see if plug-in device is available. 6.) main driver and plug-in interact via methods. 4.4. Interfaces: Interfaces exported: Interface Taxonomy Comment --------- -------- ------- BMC API Contracted Existing driver API Consolidation Private OpenIPMI Uncommitted OpenIPMI driver API Driver API OpenBMC Consolidation The new driver plug-in plug-in Private API. Interface imported: Interface Taxonomy Comment --------- -------- ------- OpenIPMI Uncommitted OpenIPMI driver API Driver API 5. References: http://openipmi.sourceforge.net/ http://openipmi.sourceforge.net/IPMI.pdf http://www.intel.com/design/servers/ipmi/index.htm 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open