David Kahn wrote: > >> 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). > > I don't know if you solved the last piece of this or not. > > We (the firmware) simply export a pseudo path for iscsi boot, > which is /iscsi-hba/disk > > the disk node has a "compatible" property, which I'm told currently > contains the value "sd". > > We could probably change that to something like "SUNW,iscsi-disk", > and the OS can bind that string to whatever driver you want to in > /etc/driver_aliases. (either bundled or via add_drv). If you want > us to change that, we can ask Tarl to do it, and we'll submit another > fast-track case for that change. But that is not something that is > or should be settable in the firmware at least to the normal used. > I can't imagine a user friendly system where the user has to configure > the name of the OS driver in the firmware that they want to use. > How would they know that? Nonetheless, it seems like the wrong thing > to want to do if you ask me. > > We don't specify OS driver bindings in the firmware. We do provide > "compatible" property value definitions with default values as > specified in specific bus bindings, based on standards. The driver > binding is always left to the OS. That's worked for us for a long > time, and it's hard to envision a case now where it doesn't work > for us, as long as devices provide some unique string that the OS > can use to bind to a device driver name. > > If you want something besides "sd" in the /iscsi-hba/disk compatible > propval, we can do that. Other than that, I'm not sure we can help > with the driver binding issue. > > -David Hi David,
There was no request to ask firmware to specify the driver name for binding in this case. Solaris will figure out right drivers to bind by dynamically assembling the bootpath, that is described as solution #3 in a previous email. That approach is with the help from FWARC/2009/498, and is opposed to the original spec of this case. I'll write up an updated spec for this case to detail the new approach (roughly described as solution #3 in previous email) based on comments received and progresses already made to solve the issue. Thank you for the help on the FWARC case, and I think that's enough to solve the issue here from firmware side. Best regards, Jack
