CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
0. Number: PSARC/2008/???
1. This contract is between
a SUPPLIER of INTERFACES and
a CONSUMER of those INTERFACES,
both of whom are entities within Sun Microsystems, Incorporated.
2. The SUPPLIER (definer and/or implementor) is identified by the following:
Product or Bundle: Solaris
Consolidation: ON
Department or Group: Solaris Core Technologies
Bugtraq Category/SubCategory: kernel/zones
Responsible Manager: Sridar Yedunuthula
3. The CONSUMER is identified by the following:
Product or Bundle: Sun Cluster
Consolidation: Sun Cluster
Department or Group: Sun Cluster Infrastructure
Bugtraq Category/SubCategory: suncluster/zone-cluster
Responsible Manager: Burt Clouse
4. The INTERFACES are:
INTERFACE STABILITY
libzonecfg: Project private for all interfaces
---------- in this library
zonecfg_init_handle
zonecfg_get_handle
zonecfg_check_handle
zonecfg_fini_handle
zonecfg_get_name
zonecfg_get_xml_handle
zonecfg_lookup_nwif
zonecfg_lookup_fs
zonecfg_lookup_ipd
zonecfg_lookup_dev
zonecfg_lookup_ds
zonecfg_lookup_rctl
zonecfg_lookup_pset
zonecfg_lookup_mcap
zonecfg_get_zonepath
zonecfg_get_pool
zonecfg_get_iptype
zonecfg_save
zonecfg_del_all_resources
zonecfg_rm_aliased_rctl
zonecfg_get_bootargs
zonecfg_get_sched_class
zonecfg_get_autoboot
zonecfg_get_aliased_rctl
zonecfg_get_limitpriv
zone_get_state
zone_get_brand
zone_get_rootpath
//
// The following identifies both the struct and the specific
// field in that struct that are used by Sun Cluster
// Sun Cluster is also dependent upon the size of the struct.
//
// For example, Sun Cluster allocates struct zone_nwiftab and passes
// that struct to Solaris code. Solaris 10 update 6 added a "defrouter"
// field to the struct. Since Sun Cluster was formerly built on top of
// Solaris 10 update 5, this caused a problem because Sun Cluster was
// not passing a big enough struct to the Solaris code.
//
struct zone_fsopt
zone_fsopt_next
zone_fsopt_opt
struct zone_fstab
zone_fs_special
zone_fs_dir
zone_fs_type
zone_fs_options
zone_fs_raw
struct zone_nwiftab
zone_nwif_address
zone_nwif_physical
zone_nwif_defrouter
struct zone_rctltab
zone_rctl_name
zone_rctl_valptr
struct zone_rctlvaltab
zone_rctlval_priv
zone_rctlval_limit
zone_rctlval_action
zone_rctlval_next
struct zone_dstab
zone_dataset_name
struct zone_devtab
zone_dev_match
struct zone_mcaptab
zone_physmem_cap
struct zone_psettab
zone_ncpu_min
zone_ncpu_max
zone_importance
//
// Sun Cluster uses all of the aliases,
// and would need to know about any new aliases.
//
ALIAS_MAXLWPS "max-lwps"
ALIAS_MAXSHMMEM "max-shm-memory"
ALIAS_MAXSHMIDS "max-shm-ids"
ALIAS_MAXMSGIDS "max-msg-ids"
ALIAS_MAXSEMIDS "max-sem-ids"
ALIAS_MAXLOCKEDMEM "locked"
ALIAS_MAXSWAP "swap"
ALIAS_SHARES "cpu-shares"
ALIAS_CPUCAP "cpu-cap"
//
// Sun Cluster uses all of the zone states,
// and would need to know about any new zone states
//
ZONE_STATE_CONFIGURED
ZONE_STATE_INCOMPLETE
ZONE_STATE_INSTALLED
ZONE_STATE_READY
ZONE_STATE_RUNNING
ZONE_STATE_SHUTTING_DOWN
ZONE_STATE_DOWN
ZONE_STATE_MOUNTED
// Sun Cluster uses this return code
Z_OK
// Sun Cluster uses the following variable type
zone_state_t
// Sun Cluster uses the following variable type
zone_dochandle_t
// Sun Cluster uses the following enum type and both
// defined enums
zone_iptype_t
.................................
Zone interfaces from zone.h Project Private
for all interfaces
zone_status_get
zone_find_by_name
zone_key_create
// We report all of the zone status states.
// We actually use in our code
// ZONE_IS_DOWN and ZONE_IS_SHUTTING_DOWN zone states.
zone_status_t
ZONE_IS_UNINITIALIZED
ZONE_IS_READY
ZONE_IS_BOOTING
ZONE_IS_RUNNING
ZONE_IS_SHUTTING_DOWN
ZONE_IS_EMPTY
ZONE_IS_DOWN
ZONE_IS_DYING
ZONE_IS_DEAD
.................................
BrandZ Interfaces Project Private
for all interfaces
// Sun Cluster does not use any libbrand.so interface.
// Sun Cluster needs notification when there are changes to the two files
// below.
/usr/share/lib/xml/dtd/zone_platform.dtd.1
/usr/share/lib/xml/dtd/brand.dtd.1
// Sun Cluster "customizes" the following "tags" from brand.dtd.1
5. The ARC controlling these INTERFACES is:
PSARC
6. The CASE describing these INTERFACES is:
PSARC/2002/174 - Virtualization and Namespace Isolation in Solaris
PSARC/2005/471 - BrandZ: Support for non-native zones
7. The following SPECIAL ARRANGEMENTS are made which modify the rules
imposed by the stability levels listed in section 4 above:
_N_ 7a. Although the stability level doesn't normally restrict it,
SUPPLIER promises to only modify INTERFACES in an incompatible
way as follows:
SUPPLIER agrees to only change the contracted interface
in an incompatible manner in a new minor release.
_N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will
expose INTERFACES to a PARTNER, which is external to Sun, namely:
Name of Company:
Name of Department or Group within Company:
Responsible Manager:
_Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will
import INTERFACES from a separate consolidation.
SUPPLIER will notify CONSUMER of any changes to the interface.
_Y_ 7d. If SUPPLIER decides to change (including replace or remove) any
portion of the INTERFACES, SUPPLIER will notify CONSUMER of the
proposed new version, no later than the application for ARC
approval of the new version.
If SUPPLIER and CONSUMER are contained in the same consolidation,
they have the option of arranging for simultaneous conversion
to the new interfaces. If this is not possible, or if they are
not in the same consolidation, then SUPPLIER will either make best
effort to work with CONSUMER so that CONSUMER can detect which
version of INTERFACES is being supplied, or else SUPPLIER will
make best effort to supply both old and new versions of INTERFACES.
If SUPPLIER cannot make both versions of INTERFACES available,
and SUPPLIER and CONSUMER cannot devise a method whereby
CONSUMER can detect which version of INTERFACES is being
supplied, and the old version of CONSUMER will not run with the
new version of SUPPLIER, then either the EOL process must be
followed by SUPPLIER, or else a major release of SUPPLIER will
be required, or the change will not be allowed.
10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
handled as follows:
SUPPLIER will notify CONSUMER of any proposed changes to the
interface.
11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
follows:
CONSUMER shall file bugster change requests against the
interfaces under solaris/kernel/zones. SUPPLIER agrees to
respond to these change requests according to the usual
sustaining process.
12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
follows:
The materials in this case.
13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
tested as follows:
SUPPLIER agrees to test any changes to the interface as part of
existing or updated test suites. CONSUMER agrees to test their
use of these interfaces at the usual release intervals and when
any changes are made to the implementation of the contracted
interface.
14. SUPPLIER and CONSUMER agree that this contract can be terminated as
follows:
Contract will be terminated by mutual agreement between the
SUPPLIER and CONSUMER.
15. This contract is not valid until "signed" via agreement from the
SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
this contract. E-mail agreement to the contract should be archived
in the mail archive of CASE; verbal agreement to the contract
should be noted in the meeting minutes. This contract remains
valid until superseded or invalidated.
For SUPPLIER: Sridar Yedunuthula Date:
For CONSUMER: Burt Clouse Date:
For ARC: ? Date:
A copy of this contract shall be deposited in the CASE directory as
"contract-" or in a "contracts" subdirectory.
16. (Not to be filled in until superseded or invalidated.)
This contract was superseded or invalidated by CASE:
For ARC: Date: