[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Freeipmi-devel] Fujitsu's iRMC S2 - support for reading/writing of
RE: [Freeipmi-devel] Fujitsu's iRMC S2 - support for reading/writing of some configspace variables within ipmi-oem
Thu, 30 Sep 2010 10:56:57 -0700
On Thu, 2010-09-30 at 05:38 -0700, Liebig, Holger wrote:
> Hi Dan & Al,
> > Hi Dan,
> > On Mon, 2010-09-27 at 02:09 -0700, Dan Lukes wrote:
> > > Hi.
> > >
> > > The Fujitsu's iRMC has implemented proprietary function for
> > > reading/writing internal configuration variables.
> > >
> > > On supported operating OSes those variables are set by ServerView
> > > drivers. On unsupported OSes they are not set.
> Unfortunately we have to limit our Server Management support to a
> number of Operating Systems. We do know that some customers are not
> happy with this and that freeipmi or other open source solutions/tools
> are used to fill some of the gaps.
> > >
> > > The IPMI interface for reading/writing configspace is proprietary
> > > interface not documented by FSC.
> Well, it is slightly more complicated than this. The configuration
> space is a higher level API for different Server Management
> implementations, where an IPMI based BMC is only one possible hardware
> solution and the number of supported config space values is System and
> BMC version dependent. Since it is a generic configuration interface
> for many different items, I do not know if it would be better to have
> a more generic solution for anything or read/write only a limited
> number of values with separate commands (for many customers ipmi-raw
> is also a solution). In the end, we normally recommend our Windows and
> DOS configuration tools or the build in Web Interface of the iRMC to
> our customers and provide information on how and what to write with
> low level API only when requested/needed.
> Based on Dan's feedback I have addressed the issue of publishing the
> IPMI command and a set of supported config space values internally,
> but it's not up to me to make the final decision. Since we also need
> to publish this information for scripting purposes, sooner or later it
> will be available. So please be patient.
Well, if there is a feeeling it could be released semi-soon, Dan are you
amenable to wait a little bit?
> > Generally speaking, I am willing to accept undocumented IPMI support.
> > However, I do wish to be on good terms with all the vendors. I
> > certainly don't want to tick off some vendor by putting something into
> > FreeIPMI they want to keep proprietary for some reason.
> > I know Holger regularly reads this mailing list. If he or anyone from
> > Fujitsu offers a blessing of sorts, then we can iterate through it and
> > eventually get this into FreeIPMI.
> For the items Dan has added support, I do not have any objections to add this
> to freeipmi.
> > Regardless of what we do, I think it'd be nice to get it published so
> > others that are interested in it would be able to download it and patch
> > their version of FreeIPMI themselves.
> I did not see the actual patch from Dan attached to the mail, it only
> contained some of the older SEL decoding code.
High Performance Systems Division
Lawrence Livermore National Laboratory