[ofw] RE: Windows Server 2008 (x64) mthca install via DPINST.EXE

[Fab Tillier]

Hi Tzachi,

Some comments inline.

Cheers,
-Fab

-----Original Message-----
> From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
> Sent: Thursday, December 13, 2007 3:34 PM
> To: Jan Bottorff; Reuven Amitai; Fab Tillier; Smith, Stan
> Cc: ofw at lists.openfabrics.org
> Subject: RE: [ofw] RE: Windows Server 2008 (x64) mthca install via DPINST.EXE
>
> Trying to combine the two threads back to one:
>
> I guess that we all agree that the co installer makes problems on LH.
> The real question is how to solve them.
>
> I must say that I'm not sure that I understand why inf installation is
> that important?

INF-based installation is what you use when you use the device manager to install a driver, and is the fundamental installation mechanism for drivers.

To quote the DDK: "The fundamental goal for device/driver installation on Windows operating systems is to make the process as simple as possible for the user. Your installation procedures should work seamlessly with the operating system's setup components. Ideally, device installation should not require any user prompts, except for the system's request to insert the distribution medium."

Requiring an installer application is contrary to this fundamental goal, not to mention it makes driver injection into a system image problematic, making deployment in clusters painful - the last thing you want is to force someone to log into 1000+ compute nodes to run some executable so that their IB gear starts to work.

> From reading Jan mails, than I see that even today he installs things
> manually (to a local disk), and than creates an image. Can you please
> add more details why it is that important?
>
> In any case, there are 3 options that I see that will allow INF
> installation:
> 1) Using a filter driver with a service (auto start). I'm not sure that
> this is a documented way.

I don't think there's anything wrong with creating a device object that isn't part of a PnP-enumerated device (say from DriverEntry), and handling multiple different device object types within a single driver.

> 2) Installing the IBBUS driver as a service only, probably much more
> documented. This server will start on demand and can probably start
> before any user mode code.

Installing as a filter driver vastly simplifies PnP handling for device relations.  The current model, where the HCA driver ask the IBAL driver for what its child devices are, could be completely handled in the filter driver and simplify the HCA driver.  The filter driver would see all PnP requests targeted at the HCA and handle all the relationship management independent of the HCA.  The filter driver could also handle these requests asynchronously, say to delay completion until scanning the fabric for IOCs is complete, which I believe will help greatly with boot-over-IB support since child IOCs will get reported in a deterministic manner.

> 3) Have the functionality of the IB-BUS exposed by mthca.sys. By this
> approach there is only one driver (mthca). MTHCA than loads the
> IBBUS.sys driver dynamically and implements it's functionality.

This isn't that much different from 1, conceptually - a single driver serves as both a functional driver (how to interact with the hardware) and a bus driver/proxy.  The problem however is if you have multiple HCAs - which HCA does an application create file handles on for non-HCA specific operations (like listening for incoming connections on all CAs)?  You probably should have a device object that is not part of a PnP-enumerated device node to handle non-device specific requests.

Furthermore, if you integrate the bus driver into MTHCA, how do you support different HCA devices?  Would other IHVs (e.g. QLogic) add code to the MTHCA driver to support their device?  Integration removes the flexibility in the stack to support multiple HW vendors.

>
> All comments are welcomed.
>
> Thanks
> Tzachi