<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [Openib-windows] [RFC] changing kernel complib to be static library</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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).</FONT></P>
<P><FONT SIZE=2>COMPLIB as a static library has more drawbacks: </FONT>
<BR> <FONT SIZE=2>1. Unsynchronized common mechanisms</FONT>
<BR> <FONT SIZE=2> Imagine, that you want to synchronize several components by taking some well-known sync object.</FONT>
<BR> <FONT SIZE=2> You will possibly implement the support to this object in COMPLIB.</FONT>
<BR> <FONT SIZE=2> If every component uses its own copy of complib, i.e - its own implementation of this mechanism - you can get into bad troubles.</FONT></P>
<P> <FONT SIZE=2>2. 3rd party users</FONT>
<BR> <FONT SIZE=2> What if some other company want to develop a ULP, using our COMPLIB. </FONT>
<BR> <FONT SIZE=2> How do you syncronize you bugfixing/developing of COMPLIB with him ?</FONT>
<BR> <FONT SIZE=2>3. Multiplied code</FONT>
<BR> <FONT SIZE=2> Imagine, that you change for some reason COMPLIB's initialization/termination sequence.</FONT>
<BR> <FONT SIZE=2> Now one needs to fix the appropiate code in ALL the components, using it, which is errorprone. </FONT>
</P>
<P><FONT SIZE=2>A DLL version check fully prevents ALL weird situations, caused - in the first place - by code duplication. </FONT>
</P>
<P><FONT SIZE=2>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).</FONT></P>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Fab Tillier [<A HREF="mailto:ftillier@silverstorm.com">mailto:ftillier@silverstorm.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, July 14, 2005 4:30 AM</FONT>
<BR><FONT SIZE=2>To: 'Leonid Keller'; openib-windows@openib.org</FONT>
<BR><FONT SIZE=2>Subject: RE: [Openib-windows] [RFC] changing kernel complib to be static</FONT>
<BR><FONT SIZE=2>library</FONT>
</P>
<BR>
<P><FONT SIZE=2>> From: Leonid Keller [<A HREF="mailto:leonid@mellanox.co.il">mailto:leonid@mellanox.co.il</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Wednesday, July 13, 2005 10:06 AM</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> i don't like the idea.</FONT>
<BR><FONT SIZE=2>> Windows' kernel consists of DLLs and they change it with service packs</FONT>
<BR><FONT SIZE=2>> anyway ...</FONT>
</P>
<P><FONT SIZE=2>Yes, and they require a reboot anytime that happens, which everyone complains</FONT>
<BR><FONT SIZE=2>about. However, this is for core kernel components. We're a loadable driver</FONT>
<BR><FONT SIZE=2>and should do everything we can to avoid a reboot.</FONT>
</P>
<P><FONT SIZE=2>> And what about IBAL.sys - it is also used now by several components ?</FONT>
</P>
<P><FONT SIZE=2>IBAL.sys is only used by ibbus.sys and by thca.sys. Every other driver uses bus</FONT>
<BR><FONT SIZE=2>interface mechanisms rather than linking directly. THCA should be changed to</FONT>
<BR><FONT SIZE=2>use the interface too, but hasn't been. I believe the only uses of ibal.sys in</FONT>
<BR><FONT SIZE=2>thca.sys are for generating nice error messages (ib_get_err_str), but I need to</FONT>
<BR><FONT SIZE=2>check. On my todo list is removing the DLL dependency between thca.sys and</FONT>
<BR><FONT SIZE=2>ibal.sys, and then making ibal.sys a static library linked into ibbus.sys (and</FONT>
<BR><FONT SIZE=2>no where else).</FONT>
</P>
<P><FONT SIZE=2>> Using a static library can bring us to kind of "DLL mess" problem, when each</FONT>
<BR><FONT SIZE=2>> driver works with its own version of COMPLIB and a bug, fixed in one version,</FONT>
<BR><FONT SIZE=2>> continues to be present in others.</FONT>
</P>
<P><FONT SIZE=2>True, however such bugs should be infrequent. Further, bugs in inline functions</FONT>
<BR><FONT SIZE=2>will not be resolved without rebuilding all drivers that use those functions.</FONT>
<BR><FONT SIZE=2>The goal isn't to allow mixing versions of the drivers, but rather allowing</FONT>
<BR><FONT SIZE=2>mixing debug and release drivers. The OS currently allows this - you can</FONT>
<BR><FONT SIZE=2>replace any driver in the system with its debug counterpart and end up with a</FONT>
<BR><FONT SIZE=2>fully functional system. That is not the case with our IB drivers, and IMO this</FONT>
<BR><FONT SIZE=2>is a pretty serious flaw. The alternative is to use macro-magic and provide</FONT>
<BR><FONT SIZE=2>support for both debug and release clients at the same time regardless of the</FONT>
<BR><FONT SIZE=2>build type of complib.sys, however this is rather cumbersome.</FONT>
</P>
<P><FONT SIZE=2>Take quick list for example. You would have to create a __qlist_item_fre_t and</FONT>
<BR><FONT SIZE=2>__qlist_item_chk_t structures, one for what a list item looks like on a free</FONT>
<BR><FONT SIZE=2>build, the other for a checked build. Then cl_list_item_t would be #defined</FONT>
<BR><FONT SIZE=2>like this:</FONT>
</P>
<P><FONT SIZE=2>#ifdef _DEBUG_</FONT>
<BR><FONT SIZE=2>#define cl_list_item_t __qlist_item_chk_t</FONT>
<BR><FONT SIZE=2>#else</FONT>
<BR><FONT SIZE=2>#define cl_list_item_t __qlist_item_fre_t</FONT>
<BR><FONT SIZE=2>#endif</FONT>
</P>
<P><FONT SIZE=2>Same goes for all functions that operate on any structure that changes between</FONT>
<BR><FONT SIZE=2>debug and release builds (which many do).</FONT>
</P>
<P><FONT SIZE=2>In any case, we need to make it so that someone doesn't hose their system by</FONT>
<BR><FONT SIZE=2>forgetting to copy a driver.</FONT>
</P>
<P><FONT SIZE=2>> May be we can use another solutions, say:</FONT>
<BR><FONT SIZE=2>> - add versioning to COMPLIB , so a new HCA driver will fail loading</FONT>
<BR><FONT SIZE=2>> upon unappropriate COMPLIB version;</FONT>
<BR><FONT SIZE=2>> - add checking of build_types of the components (also on startup);</FONT>
<BR><FONT SIZE=2>> - (the worst case) to copy all the files to system\drivers upon driver</FONT>
<BR><FONT SIZE=2>> update and require reboot! :(</FONT>
</P>
<P><FONT SIZE=2>I don't like the idea of performing runtime checks for linkage issues especially</FONT>
<BR><FONT SIZE=2>since the check would have to check both version and build type. It wouldn't be</FONT>
<BR><FONT SIZE=2>possible to mix debug and release drivers, which is something that can be done</FONT>
<BR><FONT SIZE=2>today, and can be very valuable by letting you test a single driver without</FONT>
<BR><FONT SIZE=2>incurring the timing change penalty of running the full debug stack.</FONT>
</P>
<P><FONT SIZE=2>Requiring a reboot does not provide a good user experience, so we should avoid</FONT>
<BR><FONT SIZE=2>it if at all possible.</FONT>
</P>
<P><FONT SIZE=2>- Fab</FONT>
</P>
</BODY>
</HTML>