[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] Question regarding windows version

From: Albert Chu
Subject: Re: [Freeipmi-devel] Question regarding windows version
Date: Mon, 10 Dec 2012 17:17:47 -0800

Hey Arnaud,

Generally speaking, if it mostly involves a contribution in a contrib
module, I'm pretty much game since the majority of major changes won't
have to be in the core FreeIPMI code.

We can iterate over portability patches on the mailing list, which I
imagine should be pretty easy to get through.


On Sun, 2012-12-09 at 23:34 +0100, Arnaud Quette wrote:
> Hi!
> 2012/12/6 Albert Chu <address@hidden>
>         > 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:
> - 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 -
> Debian Developer -
> Free Software Developer -
Albert Chu
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

reply via email to

[Prev in Thread] Current Thread [Next in Thread]