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

[Tzachi Dar]

OK, Hal let's try to close this.

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.

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. Also it is not clear who will give support once there
are problems, and who is
responsible that the license of the library won't change.

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

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).

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?

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
>