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

[Fab Tillier]

> From: Leonid Keller [mailto:leonid at mellanox.co.il]
> Sent: Thursday, July 14, 2005 2:55 AM
> 
> 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.

Well known synchronization objects should be implemented using named
synchronization object support as provided by the OS.  Complib is not intended
to facilitate cross-module synchronization, and I don't see any reason why it
should do so.

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

If the version of complib is good enough for them (i.e. they don't use the code
path with the bugs), then they don't care.  If they do care about the bug, the
won't mind rebuilding.

>         3. Multiplied code
>            Imagine, that you change for some reason COMPLIB's
> initialization/termination sequence.

If you look at the patch I sent, the initialization and cleanup is done using a
single instantiation of a macro (CL_INIT and CL_DEINIT in my patch), which does
the right thing based on what features a client wants to use.  It takes no
parameters, and any changes to the macro are automatically applied during
rebuild of clients.

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

Actually, the problem is that by not duplicating the code, we can't mix types of
drivers.  I haven't ever run into a case where complib was updated and an old
binary was using the previous version.  That's because the build process detects
the dependency and rebuilds all clients, so those get updated by xcopy /d when
being pushed out to the systems under test.

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

One thing I forgot to mention, which only really applies to the kernel - every
driver in the kernel will be subject to some sort of WHQL testing, likely
through code coverage.  A static library eliminates a binary, and places only
the code used by a module in the binary, which should increase the percentage of
a driver's code that gets exercised.

- Fab