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

[Tzachi Dar]

Two more questions:

1) Would you consider a co-installer that calls "CreateService" and than
starts that service an "Inf only" installation? If so than we can create
the IBBUS as a service only and still have it installed only by the INF.

2) Where can I find the documentation and an example of a filter driver?

Thanks
Tzachi 

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
> Sent: Friday, December 14, 2007 3:14 AM
> To: Tzachi Dar; Jan Bottorff; Reuven Amitai; Smith, Stan
> Cc: ofw at lists.openfabrics.org
> Subject: RE: [ofw] RE: Windows Server 2008 (x64) mthca 
> install via DPINST.EXE
> 
> 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
>