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