[openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]

[Fabian Tillier]

Hi Folks,

On 1/18/07, Michael S. Tsirkin <mst at mellanox.co.il> wrote:
> > Quoting Sasha Khapyorsky <sashak at voltaire.com>:
> > Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
> >
> > On 07:00 Thu 18 Jan     , Michael S. Tsirkin wrote:
> > > > What about pure opensource - http://sourceware.org/pthreads-win32/? It
> > > > is licensed under LGPL, I see on the net many positive reports about
> > > > stability and usability.
> > >
> > > I used it to do a windows port of linux complib at some point and opensm
> > > seemed to work fine with it. What it was lacking at that point was
> > > support for 64 bit applications, and for some reason (which is
> > > still unclear to me) there was a strong desire to run opensm in 64 bit mode.
> > > Seems to have been fixed now, BTW.
> >
> > So this seems to be good option for OpenSM on Windows. Right?
>
> No idea. Distributing a copy of the pthread DLL with opensm does not
> look like a problem. But is it worth it?

Something like the pthread DLL (or even better the static lib version)
seem like it would be light-weight enough that it might be worth it
given the benefits in keeping OpenSM in sync between Linux and
Windows.  A larger package might be a deterent to users, but that's
something the IB IHVs that support OpenSM on Windows need to find out
for themselves.  I think keeping OpenSM as a single executable or an
executable and pthread DLL that can be simply copied into place on the
target system is highly desirable.  Whether OpenSM uses pthreads or
complib threads or any other kind of thread internally doesn't really
matter to users as long as performance, stability, and usability
aren't negatively affected.

This obviously doesn't help with the logging issue, but it's a step in
making the code more simpler and more maintainable.

-Fab