<div>Hi,</div>
<div> </div>
<div>In Solution 2, the issue of WSD requiring IBAL loaded could be solved by making HCA driver as boot start SERVICE_BOOT_START (instead of current SERVICE_DEMAND_START)? IPoIB could still remain as SERVICE_DEMAND_START.
</div>
<div> </div>
<div>This will load the HCA and IBBUS (as upper filter) at the boot time, and the user mode clients would get the IBAT services available rightaway. </div>
<div> </div>
<div>This may also help getting SAN boot support for SRP, currently the IB (including SRP) drivers could not be used as boot drivers (using txtsetup.oem) during the Windows installation, because IBBUS requires Win32 co-installer which is not available at that moment.
</div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>Bhushan.</div>
<div><br> </div>
<div><span class="gmail_quote">On 5/10/07, <b class="gmail_sendername">Fab Tillier</b> <<a href="mailto:ftillier@windows.microsoft.com">ftillier@windows.microsoft.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div lang="EN-US" vlink="purple" link="blue">
<div>
<p>Hi folks,</p>
<p> </p>
<p>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.
</p>
<p> </p>
<p>I can't come up with a really good solution to this, so wanted to start a discussion for how this should be addressed.</p>
<p> </p>
<p>Solution 1: Don't fail the HCA driver installation if the co-installer can't install the IB Bus device.</p>
<p>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.
</p>
<p> </p>
<p>Solution 2: Make ibbus an upper filter for the HCA, include all its information in the HCA's INF file.</p>
<p>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.
</p>
<p> </p>
<p>Neither solution is all that great.  Any other thoughts and ideas?</p>
<p> </p>
<p>-Fab</p></div></div><br>_______________________________________________<br>ofw mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:ofw@lists.openfabrics.org">ofw@lists.openfabrics.org
</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw" target="_blank">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</a><br></blockquote>
</div><br>