This document addresses three questions from PSARC. 1) Identify what sorts of changes would likely affect S10C adversely. 2) Guidance as to how to avoid or properly address these sorts of changes. 3) A recommended scope of the "transition" duration. ---- 1) Identify what sorts of changes would likely affect S10C adversely. This section and the next are a summary of the more detailed information from the developer guide we've produced to aid developers in coping with the solaris10 brand. The guide is currently at: http://perf.eng.sun.com/twiki/bin/view/Zones/DevGuide Any time a developer makes a change, in either S10 or Solaris Next, which crosses the user/kernel boundary, they may need to take the solaris10 brand into consideration. Not all changes will impact the brand, most won't. However, we sometimes make changes across the user/kernel boundary which are hidden inside the system libraries, such as libc. Application-level code won't be impacted by these changes since applications normally don't interact directly with the kernel; they interact with the system libraries. However, since the S10 system libraries are being used within the zone, the fact that the kernel and system libraries are release in lock-step no longer applies. The following kinds of changes which cross the user/kernel boundary are ones to watch out for. * Changes in syscalls Does the change touch usr/src/uts/common/os/sysent.c? If a new syscall is added, then there probably will not be an issue. If an existing syscall is removed or changed then this will likely impact the brand. Likewise for syscall parameters: if a syscall's parameters' structures or semantics change, then the brand will almost certainly be impacted. * Changes in ioctls Changes in ioctl commands or parameters for devices that are accessible within zones will likely impact the brand. By default, zones primarily have pseudo devices available within the zone. The /dev/zfs pseudo device might be the most problematic. Disks and NICs are the devices most commonly added to zone configurations. Exclusive-stack zones, which have dedicated NIC devices and are responsible for their administration, are expected to be ubiquitous on Solaris Next. The developer guide list the default devices available within the zone. * Changes in system libraries The developer guide lists the system libraries which work closely with the kernel. If a change is made to one of those libraries, along with a change in the kernel, then that is a good indication that the brand might be impacted. * Changes in signals If signals are added or changed, that can impact the brand. * Changes in auditing or accounting If auditing or accounting change in an incompatible way, then the brand could be impacted. * Changes in /proc Changes in the /proc file system or libproc can impact the ptools or any other command linked with libproc. * Changes in native commands or daemons used within solaris10 branded zones In some cases native commands are used inside the zone. If changes are made to these commands in an incompatible way, then this could impact the brand. The developer guide lists the native commands used in the zone. * Changes in kstats kstats are generally private and unstable; however, they are consumed by various user-level utilities. If the kstats on which Solaris 10 utilities depend are removed or changed, then those utilities could break. The developer guide lists the kstats to watch out for. * Changes in privileges Adding new privileges should be OK since the S10 code in the zone won't be using those. If existing privileges are broken up or removed, then the brand could be impacted. * New platforms If new platforms are released which are only supported on Solaris Next, the brand might need enhancements for optimal performance. --- 2) Guidance as to how to avoid or properly address these sorts of changes. Again, the developer guide provides detailed information about how a developer or project team can cope with the above types of changes. In summary, these techniques are as follows. * New features In general, new features that will only exist in Solaris Next do not need to work in solaris10 branded zones because Solaris 10 programs and libraries will not expect them. * Maintain compatibility with S10 Change the (private) interfaces in a backward compatible manner. * Add emulation The brand module can be enhanced to interpose on syscalls and act as a filter between Solaris 10 and Solaris Next behaviors. This includes interposing on the ioctl syscall and translating commands and parameters from one format to the other. * Use native commands or daemons If the change is in the private interaction between a command or daemon and the kernel where no application API is involved, then the zone can be configured to use the native Solaris Next command instead of the S10 command. This assumes a certain level of compatibility in the command between S10 and Solaris Next. * Keep existing kernel support If major changes are made to the kernel, it is possible to keep the existing behavior with the solaris10 brand as the only consumer. The brand can be enhanced to interact with the legacy behavior. * Backport to Solaris 10 The changes can be backported to Solaris 10 and a patch can be produced for use in the zone. * Disallow certain configurations The brand can validate zones and disallow unsupported configurations. This would only be practical for corner cases. * Platform-specific libraries If support is added to Solaris Next for a new hardware platform but the platform will not be be supported by Solaris 10, then the associated Solaris Next psr libraries can be installed into solaris10 branded zones from the global zone. --- 3) A recommended scope of the "transition" duration. The solaris10 brand is meant as an aid for customers moving to Solaris Next and is not intended to live forever. That is, we don't see a need for this brand to be available on Solaris Next+1. We would expect that this brand would be removed from Solaris Next+1. Ideally, by the time we are doing Solaris Next+1, other V12N techniques will be ubiquitous and provide a satisfactory alternative to branded zones.