Organizations/vendors often advertise support for software or protocols based on open standards. However, I've had many experiences where it does not appear vendors understand the consequences of that advertisement. The following is an example of something I've encountered in my work.
I'm the co-author and present maintainer of FreeIPMI. If you're not familiar with what IPMI is, you can read about it in the FreeIPMI FAQ. For this discussion, the most important part to understand about IPMI is that it is an open standard which you can download here.
The IPMI standard supports many things, one of which is the ability to read sensors off a motherboard. For example, it supports the ability to read CPU temperatures and report them back to the user in Celsius (e.g. 50 degrees Celsius). The types of sensors that could exist on a motherboard are very large and cannot always be handled by IPMI. So the IPMI specification supports the ability for vendors to add OEM extensions to read non-standard sensors. For example, I've encountered a motherboard where a CPU temperature sensor was not reported in Celsius, but instead reported by flags indicating "low", "medium", "high", or "overheat." This type of sensor is not defined by the IPMI specification and is specific to just one manufacturer's motherboard.
Normally, I (as potential motherboard customer) do not know how to read and interpret an OEM specific sensor. The question is, is it fair or unfair for a vendor to keep information about an OEM specific sensor closed/hidden/secret? Is it fair or unfair to only allow an OEM specific sensor to be readable by a vendor's software instead of third-party software?
In my opinion, it depends on the sensor. In the case of a OEM CPU temperature sensor above, I believe hiding this information to be unfair. A CPU temperature sensor is a standard IPMI supported mechanism. An OEM specific CPU temperature sensor is what I call a "minor permutation" from the specification. A user/customer of IPMI would expect they could read CPU temperature sensors using third-party IPMI software.
In contrast, suppose that a sensor on the motherboard supports the ability to read a sensor quite different than what is supported in the IPMI specification (i.e. it is not a "minor permutation"). In this case, I do not believe a user/customer would have reasonable expectation for third-party IPMI software to read the sensor. So in this case, I would consider it fair to keep the information closed/hidden and only readable by vendor software.
Now, you might ask, what are reasonable expectations of a customer/user? In my opinion, it comes down to how the product is advertised. Does the product brief say that you can read motherboard sensors via IPMI? Or does it say you can read them via software X? If a vendor says the former, they should be prepared to deal with questions from customers about third party software. If they say the later, I believe customers cannot have expectations of support for third-party software.
Why is this a conversation that always comes up for me? You may have guessed it by now, but many vendors do not wish to open up and share their OEM extensions with me for inclusion in FreeIPMI. As an example, the following are several IPMI standard mechanisms.
- Configure MAC Address
- Configure IP Address
- Get firmware version
- Get product name/serial number
- Set LED
Despite the fact that they are standard mechanisms, due to minor implementation differences, they have also been implemented as OEM extensions by some vendors (see ipmi-oem). The first two (configuring MAC and IP address) are particularly egregious OEM extensions, because the OEM extension (and possibly vendor specific software) are now required for basic setup and configuration of IPMI (let alone using all the features of IPMI). [1]
Hopefully, this illustrates the expectations a user/customer/software developer would have when a vendor supports an open standard. As an addendum, I do not wish to imply that companies with IPMI OEM extensions are being evil by keeping some of their OEM extensions hidden/closed/secret. Many companies I have worked with on IPMI have been very gracious in (eventually) opening up their OEM extensions for addition into FreeIPMI (see FAQ). I believe that initial resistance from vendors is often due to poor communication rather than evil intent. For many vendors, I am a strange corner case in their customer base. Support staff folks just aren't prepared to handle the kinds of support requests I make, so their initial reaction is naturally "No, we can't do that."
[1] - As an interesting aside, I once reported to a vendor that their standard IPMI MAC address configuration functionality was broken in their firmware. The vendor responded that it was working with their software, and the bug must of have been in FreeIPMI. After much back and forth, I was able to determine that their vendor specific software was configuring the MAC address using an OEM extension, not the standard mechanism. So in this particular case, the vendor support staff was completely unaware that their software used an OEM extension. Ugh ...
No comments:
Post a Comment