[ofw] Loading drivers on LHS

[Smith, Stan]

All I can comment on is
 
  1)  KIS (Keep It Simple)
 
  2)  The desire to use the preferred MS device driver installation
tools, specifically the Driver Install Frameworks (DIFx)
http://msdn2.microsoft.com/en-us/library/ms790264.aspx .
 
As discovered during the WinOF installation adventures, the DIF (DFxApp)
for undisclosed reasons, errors out when it finds more than one driver
.inf file in the same folder; Pain-IN-The-Backside!
 
Please make sure driver architectural changes for Vista can play with
DIFx tools. I believe this is the general direction anyway, just wanted
to get the DIFx $0.02 in.  :-)
 
stan.

________________________________

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
Sent: Wednesday, May 09, 2007 5:19 PM
To: ofw at lists.openfabrics.org
Subject: [ofw] Loading drivers on LHS



Hi folks,

 

I tried loading the IB drivers on LHS (Windows Server code name
"Longhorn") and it doesn't work.  I tracked the problem down to the fact
that the driver packages are now staged to a special system folder
before being installed.  The IB co-installer uses the path of the
binaries to find the drivers for the "InfiniBand Fabric" device, but
since these didn't get staged with the HCA drivers, it fails and with it
installation of the HCA drivers fails.

 

I can't come up with a really good solution to this, so wanted to start
a discussion for how this should be addressed.

 

Solution 1: Don't fail the HCA driver installation if the co-installer
can't install the IB Bus device.

While this allows the HCA drivers to install, it doesn't install the IB
Bus, which means no user-mode app will work (no IBAL device for it to
open), and no IPoIB or other child devices (no bus driver) will be
reported to the system.  A manual installation of the drivers for the IB
bus driver is required to get things really running, so there's no
longer an automatic installation path through the device manager.
Things can be scripted with devcon to work around this, though.

 

Solution 2: Make ibbus an upper filter for the HCA, include all its
information in the HCA's INF file.

This solves the installation issue (and eliminates the co-installer),
and kernel clients will get created as needed, so it's a pretty nice
solution (it actually simplifies the PnP notifications required of HCA
drivers).  The problem is that it impacts user-mode apps.  Currently, a
user-mode client can load before any HCA is available in the system, and
use the IBAL PnP notifications to detect arrival of an HCA.  If the IB
bus driver is loaded as an upper filter, it will not be loaded until an
HCA is loaded, so user-mode applications will no longer be able to rely
on IBAL for CA PnP notifications.  This would impact WSD for sure,
though WSD depends on the IBAT device anyway for address resolution, and
this won't exist until the IB bus exists.  So WSD could be
re-architected to delay-load IBAL until there are addresses reported by
IBAT.

 

Neither solution is all that great.  Any other thoughts and ideas?

 

-Fab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20070510/ca8a2c82/attachment.html>