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: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier > > > Sent: Tuesday, February 20, 2007 11:56 PM > > > To: Hal Rosenstock > > > Cc: [email protected]; 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: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > > > > 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 > > > [email protected] > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw > > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
