On Tue, Sep 15, 2009 at 05:21:32PM +0800, Jack wrote: > Nicolas Williams wrote: > >On Mon, Sep 14, 2009 at 03:27:45PM -0400, Tarl Neustaedter wrote:
> Solaris setup the bootpath before triggering discovery - logging to > the iSCSI target for this case, therefore a correct value is very > helpful here. As it is already available during the logging process > made by OBP, to pass it to OS would be a good practice. Discovery needs to be done very early in boot. So if you want to add a DHCP option for TPGT discovery, then it has to be either implemented by the OBP or implemented in the kernel and modules in the boot archive. I think you can default TPGT for now and file the RFE for additional OBP functionality or additional kernel DHCP functionality. > >I never said that the OBP should know which driver Solaris should use. > > > >I said that the choice of driver should: a) be defaulted, b) be settable > >via boot archive and/or boot option. Administering a choice of driver > >via boot archive seems reasonable to me. Storing the full boot path in > >the boot archive is not (since it is redundant, causing yet one more > >place to update when a system's root migrates). > > > This should be an working approach, I just feel it might be a bit > complex as probably needs to figure out the administrative method, > which may involve the installer, and other utilities. Your approach has that problem too, but worse: in your scheme the boot archive needs an update every time the system's boot path migrates from one target to another, whereas that is not so in my scheme. If all you store in the boot archive is the choice of driver, and the default is a reasonable one, then very few users will need to change it, and those that do will need to change it just once. > Since there are 2 options only I think that it is a practical way to > do the selection based on trail-and-error with the default 'ssd' > driver. If the TPGT value is available, the worst case would be one > false attempt to match the path, which is proven with trivial impact > to the boot process as the relogin and rediscovery will not take > place. How does the trial-and-error approach work? Can the kernel detect that it used the wrong driver? If so, great! As for TPGT, that's a 16-bit field. You can't really try all TPGT values. Nico --
