Topics for discussion from the inception review on 5/27/09 The following items for further discussion came up during the meeting in May. 1) Need 20 questions The 20 questions are included for this review. 2) What can the ARCs do to watch for changes that could impact the brand? Non-architectural changes such as bug fixes can be made to the system which will impact the brand. We'll use a mix of developer, C-team and RTI advocate education, as well as test suites, to cope with these changes. For architectural changes, the high level criteria are changes that cross the kernel/user boundary. This would be anything that causes a cap-I flag day. The following details the kinds of changes that could impact the brand. a) Changes in system calls Does it touch usr/src/uts/common/os/sysent.c? If a new syscall is added then there is probably no issue. If an existing syscall is removed or changed in some way then this will likely impact the brand. Likewise for the parameters to the syscalls. b) Changes in ioctls Changes in ioctl commands or parameters for devices that are accessible within a zone are likely to impact the brand. The following is the list of default devices available to the branded zone, although it is also possible for the user to configure a zone with additional devices. Disks or NICs are the devices most commonly added to a zone configuration. NICs and exclusive stack zones are expected to be a more common configuration on Solaris Next since VNICs and the Crossbow project enable more interesting networking options for the branded zones. Based on explorer data, it is very uncommon for other devices to be configured inside a zone. Default devices: arp conslog console cpu/self/cpuid crypto cryptoadm dtrace/dtrace dtrace/helper dtrace/provider/* fd/* ipnet/{netif} ipnet/lo0 kstat lo0 log logindmux msglog net/{netif} null openprom poll pool ptmx pts/* random sad/user stderr stdin stdout syscon sysevent sysmsg systty tcp tcp6 ticlts ticots ticotsord tty udp udp6 urandom zconsole zero zfs Of these devices, the ioctls on /dev/zfs are currently changing the most frequently. We have also observed some changes on /dev/crypto for hardware specific support of newer SPARC processors. c) Changes in libraries The following libraries interact closely with the kernel so changes in these libraries might be indicative of a change which could impact the brand. libaio.so (a real library in s10) libbc.so libbsm.so libc.so libc_db.so libcontract.so libdlpi.so libdoor.so libdtrace.so libkstat.so libpkcs11.so (CRYPTO_GET_FUNCTION_LIST ioctl) libproc.so libproject.so librt.so (a real library in s10) librtld_db.so libzfs.so d) Changes in signals There have been no signal changes between Solaris 10 and nv but if there are in the future, then this could impact the brand. For example, Solaris 10 changed the range for real time signals as compared to Solaris 8/9 and this required emulation for those brands. e) Changes in auditing or accounting If auditing or accounting change in an incompatible way, then the brand could be impacted. Although this has not occurred between Solaris 10 and nv, this was an issue for the Solaris 8 brand on Solaris 10. f) Changes in /proc Changes in the /proc file system or libproc can impact the ptools or any other command linked with libproc. At this point there have been no /proc changes which need emulation but the lx brand does provide /proc emulation and this could be done for the solaris10 brand in the future if necessary. g) Changes in native commands used within the zone Using native commands in place of the command delivered by Solaris 10 is one technique used by the emulation. The following native commands are currently used: automount automountd ifconfig If the native command changes in an incompatible way or if any configuration files used by the command change in an incompatible way then this technique becomes problematic. h) Changes in kstats kstats are generally private and unstable, but these are consumed by various user-level utilities. If the kstats that the Solaris 10 utilities depend on are removed or changed, those utilities might break. If this happens in the future, one option is to use the the native version of the utility in place of the Solaris 10 version. Up to now this issue is hypothetical and we have not seen any issues with kstats. i) Platform-specific libraries This issue won't exist until new hardware platforms are released which are only supported by Solaris Next and not supported by Solaris 10. When new hardware platforms are released that fall into this category, then the brand should be updated so that it uses the new platform-specific library correctly. This enables applications running within the zone to leverage the libpsr optimizations for the hardware (this technique was used for the solaris8 and solaris9 brands running Solaris 10). 3) Can we see a draft of the guidelines for developers? A developer guide is being written, the current draft is at: http://perf.eng.sun.com/twiki/bin/view/Zones/DevGuide The guide contains information for developers on what the brand is, what to watch for (as described above) and what techniques can be used to enable the brand to work with future changes. These guidelines will also be available on opensolaris.org so that they are available to external developers. 4) What are we doing for exclusive stack zones? Support for exclusive stack zones is not planned for the initial phase I delivery. However, initial investigation indicates that we can use command replacement to use the native commands for configuring the NIC(s) assigned to the zone. The only current native networking command we need to use is ifconfig, although further network testing is needed before we can state that exclusive stack zones are supported. The network test suites need some work so that we can fully validate the correct network behavior inside the exclusive stack zone. 5) How will we upgrade the S10 image running inside the zone? Support for upgrading the zone image is not a phase I deliverable. The ability to upgrade the zone won't be needed until S10u9 is released. There are several options we're exploring for providing this as a long term capability. The most straightforward solution, which works today, is that customers can simply patch the zone using the patch bundle that corresponds to their target release. See: http://www.sun.com/bigadmin/features/articles/sol10patch.jsp http://blogs.sun.com/patch/date/20090618 for more details on the patch bundles. The primary drawback to this is that new functionally, delivered in new packages, won't be installed, although users can always add those packages if needed. A longer term enhancement to the brand will likely enable the zone to use a modified version of live-upgrade to upgrade the image installed in the zone. To enable this the zones will be set up in phase I using a delegated ZFS dataset for their root filesystem, similar to what is currently being done for ipkg-branded zones on OpenSolaris. With this approach the tools within the zone (enhanced lu* on future Solaris 10) will be able to manage boot environments from within the zone. 6) What will we do for audio support inside the zone? Our current plan is to disallow the use of /dev/sound/* in the solaris10 branded zones for phase I integration. Explorer data indicates that only .1% (a tenth of 1 percent) of all installed zones have /dev/sound configured. If we see any actual demand for /dev/sound to work inside a solaris10 branded zone we can revisit this as a future enhancement to the brand module. 7) What doesn't work inside the zone? The branded zones will share the same limitations as native zones on Solaris 10 in terms of what features are available. For example, capabilities such as NFS server, which doesn't work in native zones, will also not work in the branded zone. Aside from these limitations, the overall goal of the project is that anything that works in a native zone on Solaris 10 should work in a solaris10-branded zone on Solaris Next. The audio issue described above might be one limitation to that statement if it turns out that there is no justification to implement support for audio in the emulation.