Hey Al, 2011/7/21 Albert Chu <ch...@llnl.gov>
> Hey Arnaud, > > On Wed, 2011-07-20 at 13:29 -0700, Arnaud Quette wrote: > > Hey Al, > > > > 2011/7/19 Albert Chu <ch...@llnl.gov> > > > (...) > > > I assuming you mean libipmidetect? libipmidetect is > > primarily > > > used for > > > detecting if ipmi over LAN exists, not for > > identifying any > > > particular > > > component. Not sure if it would be any use for you. > > > > > > understood. we may have needs in the future, to do the same > > detection > > > over the network. > > > but for now, I've released a preliminary version of > > 'nut-ipmipsu', > > > which supports only FRU info retrieval. > > > It is available in NUT trunk, includes an m4 macro (ready > > for > > > pkgconfig, but currently using AC_CHECK_HEADERS/FUNCS), and > > an > > > abstracted IPMI implementation (only provided by FreeIPMI). > > > > > > I still have to had the sensor's info, and have 2 questions > > for you: > > > - is there a way to automatically determine which sensor is > > attached > > > to an FRU? > > > Ie, I've found that the first PSU is ID 2. But how do I know > > that > > > sensor X is the one attached to this board? > > > > > > > > Whew. It's not going to be easy. The current FRU format does > > not > > support information to point you to the specific sensor > > record. > > > > that's sad, since to an IPMI newbie like me, such a reference seems > > obviously required and mandatory. > > I was pretty sure that I was missing something around the sensor owner > > ID, order of appearance (ie the 1rst PSU FRU with the first PSU > > sensor) or alike. > > > > If you tried to match power supply names (e.g. "PS 1"), that > > would > > probably work for many motherboards. However, there is no > > guarantee > > that a motherboard would ensure the FRU power supply name > > matches the > > sensor one. In fact, I looked at one motherboard I have here, > > and they > > don't match. > > > > I *think* there is another way, but it gets complicated. You > > start to > > dig into a lot of IPMI specifics and nuances (which most of > > the FreeIPMI > > libraries naturally try to hide). > > > > If you take a look at the original ipmi-fru code, > > run_cmd_args() has a > > loop that loops through the sensor data repository (where > > records on > > each sensor are kept). That's where ipmi-fru finds the device > > IDs (e.g. > > ID 2) to look through. In the FRU SDR entry, there is another > > field for > > an fru_entity_id and fru_entity_instance (see > > freeipmi/templates/ipmi-sdr-record-format-templates.h). That > > entity ID > > and instance could be mapped to the entity-id/instance for the > > sensor > > SDR records (in combination w/ checking the sensor-type and a > > few other > > fields). This will probably work on most motherboards. > > > > However, this later part is quite complicated. You'd be > > scanning/parsing the SDR manually to find these little bits > > b/c it isn't > > normally available in libipmimonitoring. > > > > This is such a unique case, I doubt it'd be something that > > would "fit" > > along with any of the current freeipmi libraries. I can help > > you write > > something for NUT that is specific for your needs though. It > > can scan > > for FRU entries, then perhaps scan for sensor entries, and > > give you back > > record IDs?? Which can subsequently be pumped into > > libipmimonitoring > > for the specific sensors?? > > > > I understand ;-) > > do you think it involves duplicating a large chunk of the libs? > > I doubt it would be a tremendous amount of code. > glad to hear this confirmation :) > > I'm trying to weight the pros and cons, and still consider a simple > > default (that works enough) with override params for nut-ipmipsu. > > ie, default to the order of appearance (I still have to "validate" > > this), and provide psuID and sensorID params to force targets if this > > doesn't work. > > > > your help is still welcome, obviously. so thanks for your offer ;-) > > No prob. > as per your above comment, I'm interested in a code sample if you have a bit of time... > > > - the things I'm using to parse FRU (like > > ipmi_fru_parse_ctx_create) > > > and other things (lie ipmi_ctx_find_inband) are not > > available in > > > 0.7.17 (the base I'm working on, Ubuntu up to 11.04). > > > I've dug quickly the ChangeLog, but was not able to identify > > clearly > > > when these functions were added. > > > What is the minimal FreeIPMI required? > > > > > > Most of these were added in FreeIPMI 0.8.1. Many of the core > > functions > > were initially only in tools and in FreeIPMI 0.8.1 they were > > "library-ized". There could be an odd-ball function here or > > there that > > were added in FreeIPMI 1.0.1, but I think you'd be safe with > > 0.8.1. > > > > thanks for these hints. > > I'll do some compilation testing to validate the final code. > > > > > > > > > > > > > > > Hopefully that's enough to get you going. > > LMK if > > > you need > > > > some help > > > > deciphering the code more. > > > > > > > > this should not be needed, but thanks for your > > kind > > > proposition. > > > > > > > > but you should probably publish this code in > > examples/, with > > > a name > > > > like "simple-ipmi-fru.c" or alike, and highlight > > this code > > > sample a > > > > bit. > > > > > > > > > That's the plan eventually :P > > > > > > so I've a minor patch for you (attached) ;) > > > it fixes indentation (replace tabs by spaces), and a typo on > > > 'frequenc*e*y'. > > > it may also be interesting to give the example compilation > > line in the > > > file header... > > > > > > Somehow the patch came to me as 0 byte in length. Could you > > try again? > > > > strange! > > I've checked my sent mail and it was 18 Kb. > > anyway, it's attached again. > > I got it this time. Yeah, the tabbing issue was me hacking together an > example too quickly. But the typo I can put into the mainline code. > ok, thanks. > > btw, have you been able to read my "improvement ideas" mail? > > Yeah, I read it awhile back. Like many projects, there is a bit of a > momentum thing going on. I sort of logged it to memory as something for > the future to consider. > perfect, I just wanted to be sure that you at least had a ticket in mind ;-) cheers, Arnaud
_______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel