[ofw] [Fwd: Re: [openib-general] [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]

[Hal Rosenstock]

Tzachi,

On Wed, 2007-02-21 at 03:47, Tzachi Dar wrote:
> OK, Hal let's try to close this.

Thanks.

> The windows openib project was agreed by everyone to be BSD only.
> The fact that it is BSD means that any partner (or non partner) of the
> Community can download the code and use it, the way he wants.
> This includes:
> 	1) Running the code as is.
> 	2) Making changes to the code and contributing them back.
> 	3) Making changes to the code and *NOT* giving them back to the
> community.
> 
> Starting to depend on GPL (or LGPL) code means that the freedom of the
> users to do (3) is broken.
> Mellanox thinks that this needs a wider agreement of the open-IB
> consortium, which we don't have.

The package in question is licensed with LGPL. I don't think that LGPL
precludes usage #3 (although GPL precludes usage #3). See
http://www.gnu.org/licenses/lgpl.html particularly #5 and #6.

> More than that, the ideas that were introduced here about sending users
> to other places in order for
> them to find the pthread implementation are also not that great as this
> starts to make the life of our users harder.

Is this a major hurdle ? Is it substantially harder ?

> Also it is not clear who will give support once there are problems,

I would think it is from wherever they get OpenSM support. That support
may need to interact with this project on some basis. Is this different
from Linux (and pthreads) ? I agree that it is a change from the
existing model.

> and who is responsible that the license of the library won't change.

I'm not sure how to answer this one but I don't think the license can
just change. I guess if it did, we would need to deal with this when
that occurred. Are you aware of some impending change here ?

> So, I hope this closes the subject of using LGPL software in open-IB.

I don't think we're there yet...

> By the way, what implementation of pthreads were you thinking of? I have
> noticed that the first implementation that Google brings was only tested
> on uni-processor system.
> (http://sourceware.org/pthreads-win32/news.html). (this is really
> amazing, I thought that these servers were out of the market a long time
> ago).

I think that is old information and this also supports 64 bit
architectures as well.

> To be more practical:
> Can you give us a better view of what you are trying to achieve? In
> other words, as far as I know 
> Opensm is using complib apis to handle threads. The implementation of
> this functions on windows is usually trivial.
> Do you intend to make a re-write of opensm so that it will use pthreads
> or do you intend to make a find/replace
> And replace the complib functions with Pthreads ones? If we are talking
> about the second, than one can simply implement the pthread functions
> using trivial win32 calls.
> 
> And another question: What is the functionality that you are currently
> missing? Can this functionality be added?

There will be another posting addressing these questions.

-- Hal

> Thanks
> Tzachi
> 
> By the way, rumors I have heard say that Voltaire doesn't always give
> it's code back to the community, but this are just rumors, right?

> > -----Original Message-----
> > From: ofw-bounces at lists.openfabrics.org 
> > [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
> > Sent: Tuesday, February 20, 2007 11:56 PM
> > To: Hal Rosenstock
> > Cc: ofw at lists.openfabrics.org; Gilad Shainer; OPENIB
> > Subject: RE: [ofw] [Fwd: Re: [openib-general] [Fwd: Re: 
> > winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]
> > 
> > -----Original Message-----
> > From: ofw-bounces at lists.openfabrics.org
> > [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Hal Rosenstock
> > Sent: Tuesday, February 20, 2007 1:43 PM
> > 
> > On Tue, 2007-02-20 at 16:08, Fab Tillier wrote:
> > > -----Original Message-----
> > > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > > Sent: Tuesday, February 20, 2007 10:57 AM
> > > 
> > > On Tue, 2007-02-20 at 13:56, Fab Tillier wrote:
> > > [ftillier] This isn't just an install issue - it's a build issue.
> > > Anyone that wants to build OpenSM will need to find/download/install
> > the
> > > pthreads library so that the build will succeed.  If linking
> > statically,
> > > the resulting executable will not require any special installation.
> > > It's only an install issue if you link dynamically to pitheads.
> > 
> > OK; then build and install. How big an issue is this ?
> > 
> > I thought DLLs were dynamically linked but I'm a Windows plebe. 
> > 
> > [ftillier] When you build, the linker needs the import 
> > library for pthreads so that the functions get resolved as 
> > being imported from the pthreads DLL.  The dependency on the 
> > pthreads DLL is then created and the DLL will be loaded 
> > dynamically, assuming it can be found in the path.
> > 
> > So for the build process, you need to have the pthreads 
> > library available to the build tool (path to the lib).  This 
> > requires installing the pthreads developer package or however 
> > it's done.
> > 
> > If you statically link the pthreads lib, rather than 
> > dynamically link, then all the pthreads goodies go directly 
> > into the executable and you remove the dependency on an 
> > external DLL.  The build process requirements are no 
> > different than for the dynamically linked case.
> > 
> > There is also the possibility to remove the link-time 
> > dependency by calling GetProcAddress to explicitly resolve 
> > the pthreads entrypoints.
> > This method still requires having the DLL loaded on the 
> > user's systems.
> > 
> > Pesonally, I would rather see static linkage to the pthreads 
> > library so that only the builds are affected (something only 
> > 'experts' will be doing), while not affecting the common user.
> > 
> > -Fab
> > _______________________________________________
> > ofw mailing list
> > ofw at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
> >