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

[Fab Tillier]

> 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