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

[Leonid Keller]

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]
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]
> 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/7d414eac/attachment.html>