[Openib-windows] [RFC] changing kernel complib to be static l ibrary

Thu Jul 14 10:45:55 PDT 2005

see below

-----Original Message-----
From: Tzachi Dar 
Sent: Thursday, July 14, 2005 5:15 PM
To: Leonid Keller; 'Fab Tillier'; openib-windows at openib.org
Subject: RE: [Openib-windows] [RFC] changing kernel complib to be static l
ibrary

I disagree with most of the drawbacks that you have mentioned. Please note
that there is no code duplication, but rather using the same compiled code a
few times.
[Leonid Keller] Yes, it's obvious. I was talking about a siuation, that for
some reason only a part of the drivers get replaced and different
communicating components are working each with its own version of COMPLIB

As a result this means for (3) that if there is a change in the
initialization/termination sequence, there is nothing that should be changed
in other ULPs that we don't have to change today.
[Leonid Keller] Fab mentioned, that changing DLL to static library requires
adding initialization/termination code in every componet, using COMPLIB, so
...

For 3'rd partied users:

ULPs that we do have their code, we can simply recompile them as we do with
a DLL. As for 3'rd parties ULPs that we don't have their code: Using a DLL
they just crush as the dll has just changed, and they are not ready for
this. If they are using a static lib, they can still work (nothing has
changed for them).
[Leonid Keller] NO !!! They must perform version checking and fail their
startup ! 

The real drawback is the size that is increasing, but I don't think that
this is a real issue.

On the other hand most of the problems can be avoided (still using a shared
DLL) by 1) always installing both shared free/chk dlls. In this case
everyone can use what ever he wants. 2) Changing complib not to have the
structures that their size changes depending if this is a chk or free build.
[Leonid Keller] Fab told about the situation, that release and debug
versions were accidentally mixed.

But here, as i take, all agree, that we need to perform the necessary
changes to enable that mix. 

In any case, the current situation should change.

Thanks

Tzachi

-----Original Message-----
From: Leonid Keller [mailto:leonid at mellanox.co.il] 
Sent: Thursday, July 14, 2005 2:55 AM
To: 'Fab Tillier'; Leonid Keller; openib-windows at openib.org
Subject: RE: [Openib-windows] [RFC] changing kernel complib to be static l
ibrary

Checking the build type is just a temporary workaround, that will be removed
after adding support to debug/release mix (which, i agree, is very
worthful).

COMPLIB as a static library has more drawbacks: 
        1. Unsynchronized common mechanisms 
           Imagine, that you want to synchronize several components by
taking some well-known sync object. 
           You will possibly implement the support to this object in
COMPLIB. 
           If every component uses its own copy of complib, i.e - its own
implementation of this mechanism - you can get into bad troubles.

        2. 3rd party users 
           What if some other company want to develop a ULP, using our
COMPLIB. 
           How do you syncronize you bugfixing/developing of COMPLIB with
him ? 
        3. Multiplied code 
           Imagine, that you change for some reason COMPLIB's
initialization/termination sequence. 
           Now one needs to fix the appropiate code in ALL the components,
using it, which is errorprone. 

A DLL version check fully prevents ALL weird situations, caused - in the
first place - by code duplication. 

I agree with turning a single-used DLL into a static library, but i still
believe, that a commonly used component would rather be a DLL (with an
*obligatory* version checking mechanism).

-----Original Message----- 
From: Fab Tillier [ mailto:ftillier at silverstorm.com
<mailto:ftillier at silverstorm.com> ] 
Sent: Thursday, July 14, 2005 4:30 AM 
To: 'Leonid Keller'; openib-windows at openib.org 
Subject: RE: [Openib-windows] [RFC] changing kernel complib to be static 
library 

> From: Leonid Keller [ mailto:leonid at mellanox.co.il
<mailto:leonid at mellanox.co.il> ] 
> Sent: Wednesday, July 13, 2005 10:06 AM 
> 
> i don't like the idea. 
> Windows' kernel consists of DLLs and they change it with service packs 
> anyway ... 

Yes, and they require a reboot anytime that happens, which everyone
complains 
about.  However, this is for core kernel components.  We're a loadable
driver 
and should do everything we can to avoid a reboot. 

> And what about IBAL.sys - it is also used now by several components ? 

IBAL.sys is only used by ibbus.sys and by thca.sys.  Every other driver uses
bus 
interface mechanisms rather than linking directly.  THCA should be changed
to 
use the interface too, but hasn't been.  I believe the only uses of ibal.sys
in 
thca.sys are for generating nice error messages (ib_get_err_str), but I need
to 
check.  On my todo list is removing the DLL dependency between thca.sys and 
ibal.sys, and then making ibal.sys a static library linked into ibbus.sys
(and 
no where else). 

> Using a static library can bring us to kind of "DLL mess" problem, when
each 
> driver works with its own version of COMPLIB and a bug, fixed in one
version, 
> continues to be present in others. 

True, however such bugs should be infrequent.  Further, bugs in inline
functions 
will not be resolved without rebuilding all drivers that use those
functions. 
The goal isn't to allow mixing versions of the drivers, but rather allowing 
mixing debug and release drivers.  The OS currently allows this - you can 
replace any driver in the system with its debug counterpart and end up with
a 
fully functional system.  That is not the case with our IB drivers, and IMO
this 
is a pretty serious flaw. The alternative is to use macro-magic and provide 
support for both debug and release clients at the same time regardless of
the 
build type of complib.sys, however this is rather cumbersome. 

Take quick list for example.  You would have to create a __qlist_item_fre_t
and 
__qlist_item_chk_t structures, one for what a list item looks like on a free

build, the other for a checked build.  Then cl_list_item_t would be #defined

like this: 

#ifdef _DEBUG_ 
#define cl_list_item_t  __qlist_item_chk_t 
#else 
#define cl_list_item_t  __qlist_item_fre_t 
#endif 

Same goes for all functions that operate on any structure that changes
between 
debug and release builds (which many do). 

In any case, we need to make it so that someone doesn't hose their system by

forgetting to copy a driver. 

> May be we can use another solutions, say: 
>         - add versioning to COMPLIB , so a new HCA driver will fail
loading 
> upon unappropriate COMPLIB version; 
>         - add checking of build_types of the components (also on startup);

>         - (the worst case) to copy all the files to system\drivers upon
driver 
> update and require reboot! :( 

I don't like the idea of performing runtime checks for linkage issues
especially 
since the check would have to check both version and build type.  It
wouldn't be 
possible to mix debug and release drivers, which is something that can be
done 
today, and can be very valuable by letting you test a single driver without 
incurring the timing change penalty of running the full debug stack. 

Requiring a reboot does not provide a good user experience, so we should
avoid 
it if at all possible. 

- Fab 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050714/035e0971/attachment.html>