configuration.sgml

eCos操作系统源码

the value of an inactive entity has no effect on the configuration,
so this information is provided first:</PARA>
<PARA></PARA>
<SCREEN>cdl_option CYGSEM_KERNEL_EXCEPTIONS_DECODE {     
# This option is not active     
# The parent CYGPKG_KERNEL_EXCEPTIONS is disabled     
... 
};
 
...

cdl_option CYGIMP_IDLE_THREAD_YIELD {     
# This option is not active     
# ActiveIf constraint: (CYGNUM_KERNEL_SCHED_PRIORITIES == 1)     
#     CYGNUM_KERNEL_SCHED_PRIORITIES == 32     
#   --&gt; 0     
... 
}; 

</SCREEN>
<PARA>For <literal>CYGIMP_IDLE_THREAD_YIELD</literal> the
savefile lists the expression that must be satisfied if the option
is to be active, followed by the current value of all entities that
are referenced in the expression, and finally the result of evaluating
that expression.</PARA>
<PARA>Not all options are directly modifiable in the savefile. First,
the value of packages (which is the version of that package loaded
into the configuration) cannot be modified here.</PARA>
<SCREEN>

cdl_package CYGPKG_KERNEL {     
# Packages cannot be added or removed, nor can their version be changed,     
# simply by editing their value. Instead the appropriate configuration     
# should be used to perform these actions.
...
};

</SCREEN>
<PARA>The version of a package can be changed using e.g.:    </PARA>
<SCREEN>$ ecosconfig version 1.3 CYGPKG_KERNEL</SCREEN>
<PARA>Even though a package&rsquo;s value cannot be modified
here, it is still important for the savefile to contain the details.
In particular packages may impose constraints on other configurable
entities and may be referenced by other configurable entities. Also
it would be difficult to understand or extract the configuration&rsquo;s
hierarchy if the packages were not listed in the appropriate places
in the savefile.</PARA>
<PARA>Some components (or, conceivably, options) do not have any
associated data. Typically they serve only to introduce another
level in the hierarchy, which can be useful in the context of the
GUI configuration tool.</PARA>
<SCREEN>

cdl_component CYGPKG_HAL_COMMON_INTERRUPTS {     
# There is no associated value. 
}; 

</SCREEN>
<PARA>Other components or options have a calculated value. These
are not user-modifiable, but typically the value will depend on
other options which can be modified. Such calculated options can
be useful when controlling what gets built or what ends up in the
generated configuration header files. A calculated value may also
effect other parts of the configuration, for instance, via a <EMPHASIS>requires</EMPHASIS> constraint.</PARA>
<SCREEN>

cdl_option BUFSIZ {     
# Calculated value: CYGSEM_LIBC_STDIO_WANT_BUFFERED_IO ? CYGNUM_LIBC_STDIO_BUFSIZE : 0     
#     CYGSEM_LIBC_STDIO_WANT_BUFFERED_IO == 1     
#     CYGNUM_LIBC_STDIO_BUFSIZE == 256     
# Current_value: 256 
}; 

</SCREEN>
<PARA>A special type of calculated value is the <EMPHASIS>interface</EMPHASIS>.
The value of an interface is the number of active and enabled options
which <EMPHASIS>implement</EMPHASIS> that interface. Again the value
of an interface cannot be modified directly; only by modifying the
options which implement the interface. However, an interface can
be referenced by other parts of the configuration. </PARA>
<SCREEN>cdl_interface CYGINT_KERNEL_SCHEDULER {     
# Implemented by CYGSEM_KERNEL_SCHED_MLQUEUE, active, enabled     
# Implemented by CYGSEM_KERNEL_SCHED_BITMAP, active, disabled     
# This value cannot be modified here.     
# Current_value: 1     
# Requires: 1 == CYGINT_KERNEL_SCHEDULER     
#     CYGINT_KERNEL_SCHEDULER == 1     
#   --&gt; 1

</SCREEN>
<SCREEN># The following properties are affected by this value     
# interface CYGINT_KERNEL_SCHEDULER     
#     Requires: 1 == CYGINT_KERNEL_SCHEDULER 
}; </SCREEN>
<PARA>If the configurable entity is modifiable then there will be
lines like the following:</PARA>
<SCREEN> 
cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE {     
...     
# Flavor: bool     
# No user value, uncomment the following line to provide one.     
# user_value 1     
# value_source default     
# Default value: 1     
... 
}; 

</SCREEN>
<PARA>Configurable entities can have one of four different flavors:
none, bool, data and booldata. Flavor none indicates that there
is no data associated with the entity, typically it just acts as
a placeholder in the overall hierarchy. Flavor bool is the most
common, it is a simple yes-or-no choice. Flavor data is for more
complicated configuration choices, for instance the size of an array
or the name of a device. Flavor booldata is a combination of bool
and data: the option can be enabled or disabled, and there is some
additional data associated with the option as well.</PARA>
<PARA>In the above example the user has not modified this particular
option, as indicated by the comment and by the commented-out <literal>user_value</literal> line.
To disable this option the file should be edited to:</PARA>
<SCREEN>

cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE {     
...     
# Flavor: bool     
# No user value, uncomment the following line to provide one.     
user_value 0     
# value_source default     
# Default value: 1     
... 
} 

</SCREEN>
<PARA>The comment preceding the <literal>user_value
0</literal> line can be removed if desired, otherwise it
will be removed automatically the next time the file is read and
updated by the configuration tools.</PARA>
<PARA>Much the same process should be used for options with the
data flavor, for example:</PARA>
<SCREEN> 
cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_OFFSET {     
# Flavor: data     
# No user value, uncomment the following line to provide one.     
# user_value 3600     
# value_source default     
# Default value: 3600     
# Legal values: -90000 to 90000 
}; 

</SCREEN>
<PARA>can be changed to:</PARA>
<SCREEN>

cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_OFFSET {     
# Flavor: data     
user_value 7200     
# value_source default     
# Default value: 3600     
# Legal values: -90000 to 90000 }; 

</SCREEN>
<PARA>Note that the original text provides the default value in
the <literal>user_value</literal> comment,
on the assumption that the desired new value is likely to be similar
to the default value. The <literal>value_source</literal> comment
does not need to be updated, it will be fixed up if the savefile
is fed back into the configuration system and regenerated.</PARA>
<PARA>For options with the booldata flavor, the <literal>user_value</literal> line
needs take two arguments. The first argument is for the boolean
part, the second for the data part. For example:</PARA>
<SCREEN> 
cdl_component CYGNUM_LIBM_COMPATIBILITY {     
# Flavor: booldata     
# No user value, uncomment the following line to provide one.    
# user_value 1 POSIX     
# value_source default     
# Default value: 1 POSIX     
# Legal values:  &ldquo;POSIX&rdquo; &ldquo;IEEE&rdquo; &ldquo;XOPEN&rdquo; &ldquo;SVID&rdquo;     
... 
}; 

</SCREEN>
<PARA>could be changed to:</PARA>
<SCREEN> 
cdl_component CYGNUM_LIBM_COMPATIBILITY {     
# Flavor: booldata     
user_value 1 IEEE     
# value_source default     
# Default value: 1 POSIX     
# Legal values:  &ldquo;POSIX&rdquo; &ldquo;IEEE&rdquo; &ldquo;XOPEN&rdquo; &ldquo;SVID&rdquo;     
... 
}; 

</SCREEN>
<PARA>or alternatively, if the whole component should be disabled,
to:</PARA>
<SCREEN> 
cdl_component CYGNUM_LIBM_COMPATIBILITY {     
# Flavor: booldata     
user_value 0 POSIX     
# value_source default     
# Default value: 1 POSIX     
# Legal values:  &ldquo;POSIX&rdquo; &ldquo;IEEE&rdquo; &ldquo;XOPEN&rdquo; &ldquo;SVID&rdquo;     
... 
}; 

</SCREEN>
<PARA>Some options take values that span multiple lines. An example
would be:</PARA>
<SCREEN>

cdl_option CYGDAT_UITRON_MEMPOOLVAR_INITIALIZERS {     
# Flavor: data     
# No user value, uncomment the following line to provide one.     
# user_value \     
# &ldquo;CYG_UIT_MEMPOOLVAR( vpool1, 2000 ), \\     
#  CYG_UIT_MEMPOOLVAR( vpool2, 2000 ), \\     
#  CYG_UIT_MEMPOOLVAR( vpool3, 2000 ),&rdquo;     
# value_source default     
# Default value: \     
#     &ldquo;CYG_UIT_MEMPOOLVAR( vpool1, 2000 ), \\     
#      CYG_UIT_MEMPOOLVAR( vpool2, 2000 ), \\     
#      CYG_UIT_MEMPOOLVAR( vpool3, 2000 ),&rdquo; 
}; 

</SCREEN>
<PARA>Setting a user value for this option involves uncommenting
and modifying all relevant lines, for example:</PARA>
<SCREEN>

cdl_option CYGDAT_UITRON_MEMPOOLVAR_INITIALIZERS {     
# Flavor: data     
user_value \     
&ldquo;CYG_UIT_MEMPOOLVAR( vpool1, 4000 ), \\      
CYG_UIT_MEMPOOLVAR( vpool2, 4000 ),&rdquo;     
# value_source default     
# Default value: \     
#     &ldquo;CYG_UIT_MEMPOOLVAR( vpool1, 2000 ), \\     
#      CYG_UIT_MEMPOOLVAR( vpool2, 2000 ), \\     
#      CYG_UIT_MEMPOOLVAR( vpool3, 2000 ),&rdquo; 
}; 

</SCREEN>
<PARA>In such cases appropriate care has to be taken to preserve
Tcl syntax, as discussed below.</PARA>
<PARA>The configuration system has the ability to keep track of
	  several different values for any given option. All options
	  start off with a default value, in other words their value
	  source is set to <literal>default</literal>. If a
	  configuration involves conflicts and the configuration
	  system&rsquo;s inference engine is allowed to resolve these
	  automatically then it may provide an
	  <literal>inferred</literal> value instead, for
	  example:</PARA>
<SCREEN>

cdl_option CYGMFN_KERNEL_SYNCH_CONDVAR_TIMED_WAIT {     
# Flavor: bool     
# No user value, uncomment the following line to provide one.     
# user_value 1     
# The inferred value should not be edited directly.     
inferred_value 0     
# value_source inferred     
# Default value: 1     
... 
}; 

</SCREEN>
<PARA>Inferred values are calculated by the configuration system
and should not be edited by the user. If the inferred value is not
correct then a user value should be substituted instead:</PARA>
<SCREEN>

cdl_option CYGMFN_KERNEL_SYNCH_CONDVAR_TIMED_WAIT {     
# Flavor: bool     
user_value 1     
# The inferred value should not be edited directly.     
inferred_value 0     
# value_source inferred     
# Default value: 1     
... 
}; </SCREEN>
<PARA>The inference engine will not override a user value with an
inferred one. Making a change like this may well re-introduce a
conflict, since the inferred value was only calculated to resolve
a conflict. Another run of the inference engine may find a different
and more acceptable way of resolving the conflict, but this is not guaranteed
and it may be up to the user to examine the various dependencies
and work out an acceptable solution.</PARA>
<PARA>Inferred values are listed in the savefile because the exact
inferred value may depend on the order in which changes were made
and conflicts were resolved. If the inferred values were absent
then it is possible that reloading a savefile would not exactly