[Openib-windows] Re: Complib changes to support OpenSM in OpenIB

Fab Tillier ftillier at silverstorm.com
Tue Aug 30 10:37:49 PDT 2005


> From: Eitan Zahavi [mailto:eitan at mellanox.co.il]
> Sent: Tuesday, August 30, 2005 12:21 AM
> 
> Fab Tillier wrote:
> > What is the problem with keeping qlockpool in opensm?
> To have qlockpool be part of OpenSM we will need to:
> 1. Modify its implementation to be all static inline

No, the static inline is a requirement I am imposing if qlockpool is going to be
in the complib include directory.  What you do within OSM is totally up to you.
You can keep a header and implementation separate if you like.  You don't even
have to eliminate OSM's version of complib - all you have to do is make sure
things build properly without creating conflicts in headers between your shadow
copy of complib and the mainline version.  It's up to you if you want to
duplicate complib in OSM or not - as long as you don't screw things up when
using the access layer (which uses the DLL version), I don't care.

> 2. Change all files including it to use <opensm/cl_qlock_pool.h> and not
> <complib/cl_qlock_pool.h>

What prevents you from keeping the complib subdirectory to the OSM directory to
hold the qlockpool files (like you have today) and keeping these files there?
Your makefiles already account for this, the files are already there - this is
less work than moving the files at all!  Changing the directory structure is
something you are imposing on yourself.

> Making qlockpool be part of complib requires:
> 1. Add qlocpool.h to the SOURCES file in the complib dir. One file change!

You mean qlockpool.c, right?  The result is that complib now gets bloated
exporting functions that I would rather not see anyone use.

> We can do either or.
> The argument was about not USING qlockpool in OpenSM which is a much bigger
> issue.

The argument is that I don't want to see usage of qlockpool expand beyond OSM
and thus would rather it didn't go into the mainline complib.  I'd like to see
OSM evaluate its use of qlockpool because I think it may well be unnecessary,
but that's up to you to do and I don't care one way or the other if it happens
or not.  I do, however, care about bloating the complib DLLs with what I
consider useless abstraction.

As I said before, if you make qlockpool.h contain a fully static inline
implementation, we can put the header in the complib include directory.  This
requires no changes to the SOURCES files for complib, doesn't bloat the DLL, and
gets you your header in a common place.  It does require you to convert the
implementation to be static inline, which should take maybe all of 5 minutes.

- Fab





More information about the ofw mailing list