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

Wed Feb 21 06:38:40 PST 2007

On Wed, 2007-02-21 at 09:31, Hal Rosenstock wrote:
> 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.

I think I found what you were referring to:

http://sources.redhat.com/pthreads-win32/news.html

RELEASE 2.8.0
-------------
Testing and verification
------------------------
This release has not yet been tested on SMP architechtures. All tests
pass on a uni-processor system.

RELEASE 2.7.0
-------------
Testing and verification
------------------------
This release has been tested (passed the test suite) on both
uni-processor and multi-processor systems.

Release 2.8.0 is relatively new (2006-12-22).

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