X hits on this document

PDF document

February 10, 2006 - page 21 / 238





21 / 238

Chapter 2


So now we’ve got a BMC, MCs, and things like that. But how are you expected to use raw IPMI?

The first things you must do, of course, is connect to the BMC. If it’s a direct SMI connection (A SMIC, KCS, or BT interface, or perhaps a non-standard serial interface), you just open the driver on the operating system and start messaging. If it’s a LAN-type connection, you have to go through an authentication sequence. One you have a connection to the BMC, things are pretty much the same no matter what interface you have. There are a few messaging for doing special controls on a LAN interface, but they don’t generally matter to the user.

Once the connection to the BMC is up, the user should query to see what channels the BMC supports. For 1.5 and later, it gets this from a command. For 1.0, it gets it from the main SDR repository.

Once you are connected, you should scan the SDRs in the main SDR repository for any entities and sensors. Sensors and entities may also be in the device SDR repository, which should be scanned next. This allows the user to discover the sensors in the system. Note that the sensors may point to entities that don’t have a entry in the SDR that defines them, those entities need to be handled when they are detected.

After this point in time, the interface could be deemed to be “up”. However, there’s still more to do.

If the interface supports an event queue, the user will have to poll it (if the driver doesn’t deliver them asynchronously, that is). If the interface doesn’t support an event queue the user should periodically scan the system event log for new events. (Note that even if it does support an event queue, the user should still poll the system event log in case the event queue missed any events coming in.)

Also, the user should start scanning the IPMB bus with broadcast get device id commands to detect any MCs on the bus.

This is what the OpenIPMI library does for you. Beyond this, it also represents the sensors, controls, and entities in a nice OO fashion, and it handles the details of addressing, message routing, and other things you don’t really care about. It lets you get right at the sensors and entities.


The User View

A bunch of acronyms have just been introduced, along with a lot of vague concepts, and some description about how to use IPMI. The nice thing is that the user of OpenIPMI doesn’t really have to know about all these things.


Document info
Document views1159
Page views1159
Page last viewedTue Jan 24 05:24:26 UTC 2017