Hi! 2012/12/6 Albert Chu <[email protected]>
> > How does this is ported with Cygwin ? (or is it ported ?) > > I ported it to Cygwin but naturally the only thing that could be tested > was out of band communication. In band communication was untested. > > > Is it possible to get-rid of those drivers in a first porting effort, > > or is it a required part of the project ? > > If you don't care about inband communication, it really isn't necessary > to port it. It could simply be #ifdef'd out. Hypothetically a > configure option for "--no-inband" could be made. > though a first porting effort can concentrate on outband, in the end, I'm both interested in inband and outband, with more weight on inband (for local power monitoring and protection). > As Patrick said, ipmiutil uses a Windows based driver. So I assume > there is a way to add a "Windows driver" into FreeIPMI to use. > Presently there is a KCS driver (w/ ports to work on Linux & BSD), SSIF > driver, OpenIPMI (/dev/ipmi0 on many Linux systems), and SunBMC (for > Solaris). There's no reason we can't add "WinIntel" or something. I'll definitely dig (quickly) ipmiutil in that regard. > B/c > I don't have a Windows system to try on, I've just never been able to > add anything for Windows. > as told, we do have some. Though we've not played with these yet, we will try to check these quickly. anything special you would like us to look at? I'll check with Fred to test ipmiutil (from a quick discussion, he thinks he did already). Moreover, as you will see below, you won't need a windows box anymore for compiling. Al, if you're ok, I'd like to propose you the following approach, to optimize this port: - we provide a script and doc (attached) for cross compiling Windows binaries from Linux, using mingw-w64. Though it's not yet working, in the end, it will make things easy and straightforward. It will also help us to focus on what matters: the end result, and not the showstoppers. Note that this script is loosely based against another one I'm writing for NUT: http://trac.networkupstools.org/projects/nut/changeset/3821 - you (Al) check the compilation, and start fixing trivial things, more efficiently than us. - we can (and will) provide code snippets, such as for getpwuid_r() (not applicable on Windows) - we (Fred or me) can also provide pro-active patches, that you can then adapt, if you prefer - we (Fred or me) will test compilation (not sure, MSVC) and execution of ipmiutil I've made a quick test, while developing the attached script, and it turns out that: - for a first iteration, I've disabled crypto (requires libgcrypt port), and you may want to disable some more... - we will have to actually port a few things, such as crypto, kernel/HW access, ... but this can be for a 2nd round. Would that approach suits you Al? cheers, Arnaud -- NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr
freeipmi-mingw-w64.diff
Description: Binary data
_______________________________________________ Freeipmi-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-devel
