Hi Holger, Thanks for the patch. I already fixed 1 or 2 in the mainline, but you caught a few more. A few comments.
+#if defined __CYGWIN__ /* HLiebig: no Open IPMI driver support on cygwin */ + return (-1); +#else Actually I found there is a macro (__USE_LINUX_IOR_MACROS or something like that) that actually defines things in ioctl.h so it can compile. But, as we discussed in the other e-mail, it's probably best to put some type of --no-openipmi-driver and/or --no-sunbmc-driver into the autoconf to give the option to disable it all. +#if defined __CYGWIN__ +/* HLiebig: +// This is a slightly modified version based on the ipmitool network receive code from ipmitool.sourceforge.net +// It seems that recvfrom has some problems under cygwin see (Link pointed out by Al Chu ) +// This definitely makes things work. However, after playing under cygwin a bit more, it appears that it might not be recvfrom vs. recv (for this particular case). It might be that generically cygwin/winsock has slightly different recv/recvfrom semantics (maybe not posix compliant? dunno). This approach definitely is something that will be worked in one way or another, I'm wondering if possibly outside of ipmi_lan_recvfrom instead of inside it. - "Fujitsu Siemens Computers", /* 10368 */ + "Fujitsu Technology Solutions", /* 10368 */ I actually auto-generate this table/file via the Iana enterprise database http://www.iana.org/assignments/enterprise-numbers. Any chance Fujitsu is working on getting that updated? I'm somewhat reluctant to change the table. At a minimum, this change will get wiped out whenever I decide to re-download the database. If it's important to have FTS in there, we can handle it has a "special case" similar to how I handle a special case Supermicro manufacturer ID (it's an unregistered ID, so I handle it as a one-off). See libfreeipmi/src/util/ipmi-iana-enterprise-numbers-util.c. Al On Fri, 2009-12-11 at 12:36 +0100, Liebig, Holger wrote: > Hi, > I had some minor problems compiling the actual 0.8.1/0.7.16 versions under > cygwin. > > Also there seems to be a problem with the recvfrom() networking function > under cygwin, so I used a slightly modified receive function borrowed from > ipmitool which uses recv() instead of recvfrom() in order to use freeipmi > with outofband access. > > Thanks, > Holger > > -- > Holger L i e b i g > [email protected] Fujitsu Technology Solutions GmbH > Senior Developer Domagkstrasse 28 > TSP x86 E SW 4 80807 Munich > Telephone: +49 89 3222 2288 GERMANY > Telefax : +49 89 3222 329 2288 > Internet http://*ts.fujitsu.com > Company Details http://*de.ts.fujitsu.com/imprint.html > > > > _______________________________________________ > Freeipmi-devel mailing list > [email protected] > http://*lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
