On 10/16/08 13:18, Krishna Yenduri wrote: > Couple of questions on the requirements and design. Not a code review. > - What happens when an S10 system is upgraded to a Nevada build? Let us > assume that the Nevada build is using SVR4 packaging. Assume the S10 > system has a modified kcf.conf file.
*Background* S10 or previous Nevada kcf.conf files had a configuration line for each kernel software provider. *New Behavior (or Behaviour, if you wish)* The kcf.conf file on installation contains only comment lines. Upgrades do not touch the kcf.conf file. kcf.conf entries are optional, but tolerated. They are always required when a provider has disabled mechanisms. In other words, the OpenSolaris with these proposed chanes will function the same whether or not it has an old kcf.conf file with all the software providers listed or with an empty kcf.conf file. (this has been tested with empty kcf.conf files and S10-style kcf.conf files) > Can you describe step-by-step how a non-ON or third-party hardware > provider (like SCA6000) > is supposed to work in the new world? This will be useful documentation > to provide > to provider writers. *Background* The only entries previously required for hardware providers (whether or not ON/non-on or third-party) were the (pseudo) comment "#driver_names=XXXXXX entries. These comment entries are no longer required and are ignored. The driver_name comments were only used by cryptoadm as a guide for where to insert driver-specific provider configuration lines. *New Requirements* The driver_names comment entries are no longer required, but are tolerated. They are ignored if present. (this has been tested with the mca driver for the SCA 6000 Mars card) -- This message posted from opensolaris.org
