A. Introduction

This case slightly alters the behavior of dispadmin(1M)'s '-d' option,
and adds a new -u option.  A portion of the case describes the background
and design considerations; these are provided to justify the new
interfaces, but should be regarded as implementation detail.

The case seeks minor release binding and will be delivered concurrently
with the Greenline project [1].

The stability of the -d option is already 'evolving', and this does not
change as part of this case [2].  The stability of the new -u option is
requested to be consolidation private, as it is only needed at system
bootup, and is not useful thereafter.


B. Interface Table

Interface		Stability		Notes
---------------------------------------------------------------------
dispadmin -d		Evolving 		Minor behavior change
dispadmin -u		Consolidation Private   New interface


C. Background

The advent of Solaris Zones [3] caused a minor problem with scheduling
classes and zones [4]. 

In short, the problem is that when booting up a zone, the zones
infrastructure does not reset the scheduling class to the system
default.  Instead, whatever scheduling class is in use by the launching
process is used, due to the inheritance of scheduling class across
fork(2).

Greenline alters and exacerbates this problem, because zone bootup has
been reworked to cope with the contract subsystem [5].  Briefly,
init(1M) for a zone is now launched directly from the kernel (mirroring
the launch of the global zone's init daemon) when the zone is booted;
previously, init was launched via fork(2) and zone_enter(2) from the
global zone.


D. Solution

We propose that the kernel should be informed of the default scheduling
class for the system when that setting is altered.  When dispadmin -d is
run, the kernel is now updated with the new default class setting; when
zones are subsequently booted or rebooted, they will be impacted by the
new default class setting, as init(1M) will be launched in the new
default class.  This makes sense-- the granularity of the dispadmin
change is "the reboot" (and whether that is "the reboot" of a zone or of
the global zone does not matter).

Finally, at boot time, a new dispadmin flag (-u, mirroring similar flags
in dumpadm(1M) and coreadm(1M)) is needed to inform the kernel about the
administrator's choice of default scheduling class, if any.


E. Proposed Manual Page Changes

@@ -48,8 +48,9 @@
            scheduling class is displayed. If class name is speci-
            fied  and is a valid scheduling class name, then it is
            saved  in  dispadmin's  private   configuration   file
-           /etc/dispadmin.conf.  Only  super-users  can  set  the
-           default scheduling class.
+           /etc/dispadmin.conf.  Subsequent to setting the default
+           class, booting or rebooting non-global zones will cause
+           those zones to run using the new default class setting.
+           Only super-users can set the default scheduling class.

      -g    Gets the parameters for the specified class and writes
            them  to the standard output. Parameters for the real-


F. References

1. <a href="../../2002/547/">PSARC/2002/547, Greenline</a>

2. <a href="../../2000/452/">PSARC/2000/452, Revised Share Scheduler.</a>

3. <a href="../../2002/174/">PSARC 2002/174, Virtualization and Namespace Isolation in Solaris</a>

4. <a href="http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5004847">Bug 5004847</a> "'init' in non-global zones should follow system default
   scheduling class"

5. <a href="../../2003/193">PSARC 2003/193, Solaris Contracts</a>