editing-an-ecos-savefile.html

encos_rtos一款精致小巧的实时嵌入式操作系统 ＋CODEWORR 教程

very useful information so it is provided in a comment.</P
><P
>Occasionally the user will want to do some experimentation,
and temporarily switch an option from a user value back to a default
or inferred one to see what the effect would be. This could be achieved
by simply commenting out the user value. For instance, if the current
savefile contains:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="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 user     
# Default value: 1     
... 
}; &#13;</PRE
></TD
></TR
></TABLE
><P
>then the inferred value could be restored by commenting out
or removing the <TT
CLASS="LITERAL"
>user_value</TT
> line:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="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 user     
# Default value: 1     
... 
}; &#13;</PRE
></TD
></TR
></TABLE
><P
>This is fine for simple values. However if the value is complicated
then there is a problem: commenting out the <TT
CLASS="LITERAL"
>user_value</TT
> line
or lines means that the user value becomes invisible to the configuration system,
so if the savefile is loaded and then regenerated the information
will be lost. An alternative approach is to keep the <TT
CLASS="LITERAL"
>user_value</TT
> but
explicitly set the <TT
CLASS="LITERAL"
>value_source</TT
> line,
for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;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     
... 
}; &#13;</PRE
></TD
></TR
></TABLE
><P
>In this case the configuration system will use the inferred
value for the purposes of dependency analysis etc., even though
a user value is present. To restore the user value the <TT
CLASS="LITERAL"
>value_source</TT
> line
can be commented out again. If there is no explicit <TT
CLASS="LITERAL"
>value_source</TT
> then
the configuration system will just use the highest priority one:
the user value if it exists; otherwise the inferred value if it
exists; otherwise the default value which always exists.</P
><P
>The default value for an option can be a simple constant,
or it can be an expression involving other options. In the latter
case the expression will be listed, together with the values for
all options referenced in the expression and the current result
of evaluating that expression. This is for informational purposes
only, the default value is always recalculated deterministically
when loading in a savefile.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;cdl_option CYGBLD_GLOBAL_COMMAND_PREFIX {     
# Flavor: data     
# No user value, uncomment the following line to provide one.     
# user_value arm-elf     
# value_source default     
# Default value:  CYGHWR_THUMB ? &#8220;thumb-elf&#8221; : &#8220;arm-elf&#8221;     
#     CYGHWR_THUMB == 0     
#   --&gt; arm-elf 
}; &#13;</PRE
></TD
></TR
></TABLE
><P
>For options with the data or booldata flavor, there are likely
to be constraints on the possible values. If the value is supposed
to be a number in a given range and a user value of &#8220;<TT
CLASS="LITERAL"
>hello
world</TT
>&#8221; is provided instead then there
are likely to be compile-time failures. Component developers can
specify constraints on the legal values, and these will be listed
in the savefile.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
> 
cdl_option X_TLOSS {     
# Flavor: data     
# No user value, uncomment the following line to provide one.     
# user_value 1.41484755040569E+16     
# value_source default     
# Default value: 1.41484755040569E+16     
# Legal values: 1 to 1e308 
};&#13;</PRE
></TD
></TR
></TABLE
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="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:  &#8220;POSIX&#8221; &#8220;IEEE&#8221; &#8220;XOPEN&#8221; &#8220;SVID&#8221;     
... 
};&#13;</PRE
></TD
></TR
></TABLE
><P
>In some cases the legal values list may be an expression involving
other options. If so then the current values of the referenced options
will be listed, together with the result of evaluating the list
expression, just as for default value expressions.</P
><P
>If an illegal value is provided then this will result in a
conflict, listed in the conflicts section of the savefile. For more
complicated options a simple legal values list is not sufficient
to allow the current value to be validated, and the configuration
system will be unable to flag conflicts. This issue will be addressed in
future releases of the configuration system.</P
><P
>Following the value-related fields for a given option, any <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>requires</I
></SPAN
> constraints belonging
to this option will be listed. These constraints are only effective
if the option is active and, for bool and booldata flavors, enabled.
If some aspect of <SPAN
CLASS="PRODUCTNAME"
>eCos</SPAN
> functionality is inactive or disabled then
it cannot impose any constraints on the rest of the system. As usual,
the full expression will be listed followed by the current values
of all options that are referenced and the result of evaluating
the expression:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;cdl_option CYGSEM_LIBC_TIME_TIME_WORKING {     
...     
# Requires: CYGPKG_DEVICES_WALLCLOCK     
#     CYGPKG_DEVICES_WALLCLOCK == current     
#   --&gt; 1 
};&#13;</PRE
></TD
></TR
></TABLE
><P
>When modifying the value of an option it is useful to know
not only what constraints the option imposes on the rest of the
system but also what other options in the system depend in some
way on this one. The savefile provides this information:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>cdl_option CYGFUN_KERNEL_THREADS_TIMER {     
...     
# The following properties are affected by this value     
# option CYGMFN_KERNEL_SYNCH_CONDVAR_TIMED_WAIT     
#     Requires: CYGFUN_KERNEL_THREADS_TIMER     
# option CYGIMP_UITRON_STRICT_CONFORMANCE     
#     Requires: CYGFUN_KERNEL_THREADS_TIMER     
# option CYGSEM_LIBC_TIME_CLOCK_WORKING     
#     Requires: CYGFUN_KERNEL_THREADS_TIMER 
}; &#13;</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN2847">Tcl Syntax</H2
><P
><SPAN
CLASS="PRODUCTNAME"
>eCos</SPAN
> savefiles are implemented as Tcl scripts, and are read
in by running the data through a standard Tcl interpreter that has
been extended with a small number of additional commands such as <TT
CLASS="LITERAL"
>cdl_option</TT
> and <TT
CLASS="LITERAL"
>cdl_configuration</TT
>.
In many cases this is an implementation detail that can be safely
ignored while editing a savefile: simply replacing a <TT
CLASS="LITERAL"
>1</TT
> with
a <TT
CLASS="LITERAL"
>0</TT
> to disable some functionality
is not going to affect whether or not the savefile is still a valid
Tcl script and can be processed by a Tcl interpreter. However, there
are more complicated cases where an understanding of Tcl syntax
is at least desirable, for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;cdl_option CYGDAT_UITRON_MEMPOOLVAR_EXTERNS {
     # Flavor: data
     user_value \
      &#8220;static char vpool1\[ 2000 \], \\
      vpool2\[ 2000 \], \\
       vpool3\[ 2000 \];&#8221;     
# value_source default     
# Default value: \
     #     &#8220;static char vpool1\[ 2000 \], \\
     #      vpool2\[ 2000 \], \\
    #      vpool3\[ 2000 \];&#8221; 
};&#13;</PRE
></TD
></TR
></TABLE
><P
>The backslash at the end of the <TT
CLASS="LITERAL"
>user_value</TT
> line
is processed by the Tcl interpreter as a line continuation character.
The quote marks around the user data are also interpreted by the
Tcl interpreter and serve to turn the entire data field into a single
argument. The backslashes preceding the opening and closing square
brackets prevent the Tcl interpreter from treating these characters
specially, otherwise there would be an attempt at <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>command
substitution</I
></SPAN
> as described below. The double backslashes
at the end of each line of the data will be turned into a single
backslash by the Tcl interpreter, rather than escaping the newline
character, so that the actual data seen by the configuration system
is:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;static char vpool1[ 2000 ], \
      vpool2[ 2000 ], \
      vpool3[ 2000 ];&#13;</PRE
></TD
></TR
></TABLE
><P
>This is of course the data that should end up in the &micro;ITRON
configuration header file. The opening and closing braces surrounding
the entire body of the option data are also significant and cause
this body to be passed as a single argument to the <B
CLASS="COMMAND"
>cdl_option</B
> command.
The closing semicolon is optional in this example, but provides
a small amount of additional robustness if the savefile is edited
such that it is no longer a valid Tcl script. If the data contained
any <TT
CLASS="LITERAL"
>$</TT
> characters then
these would have to be treated specially as well, via a backslash escape.</P
><P
>In spite of what all the above might seem to suggest, Tcl
is actually a very simple yet powerful scripting language: the syntax
is defined by just eleven rules. On occasion this simplicity means
that Tcl&#8217;s behaviour is subtly different from other languages,
which can confuse newcomers.</P
><P
>When the Tcl interpreter is passed some data such as <TT
CLASS="LITERAL"
>puts
Hello</TT
>, it splits this data into a command and its
arguments. The command will be terminated by a newline or by a semicolon,
unless one of the quoting mechanisms is used. The command and each
of its arguments are separated by white space. So in the following
example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>puts Hello 
set x 42 </PRE
></TD
></TR
></TABLE
><P
>will result in two separate commands being executed. The first
command is <TT
CLASS="LITERAL"
>puts</TT
> and is passed a
single argument, <TT
CLASS="LITERAL"
>Hello</TT
>. The second
command is <TT
CLASS="LITERAL"
>set</TT
> and is passed two
arguments, <TT
CLASS="LITERAL"
>x</TT
> and <TT
CLASS="LITERAL"
>42</TT
>.
The intervening newline character serves to terminate the first
command, and a semi-colon separator could be used instead: </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>puts Hello;set x 42</PRE
></TD
></TR
></TABLE
><P
>Any white space surrounding the semicolon is just ignored
because it does not serve to separate arguments.</P
><P
>Now consider the following:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>set x Hello world</PRE
></TD
></TR
></TABLE
><P
>This is not valid Tcl. It is an attempt to invoke the <TT
CLASS="LITERAL"
>set</TT
> command
with three arguments: <TT
CLASS="LITERAL"
>x</TT
>, <TT
CLASS="LITERAL"
>Hello</TT
>,
and <TT
CLASS="LITERAL"
>world</TT
>. The <TT
CLASS="LITERAL"
>set</TT
> only
takes two arguments, a variable name and a value, so it is necessary
to combine the data into a single argument by quoting:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>set x &#8220;Hello world&#8221;</PRE
></TD
></TR
></TABLE
><P
>When the Tcl interpreter encounters the first quote character
it treats all subsequent data up to but not including the closing
quote as part of the current argument. The quote marks are removed
by the interpreter, so the second argument passed to the <TT
CLASS="LITERAL"
>set</TT
> command
is just <TT
CLASS="LITERAL"
>Hello world</TT
> without the
quote characters. This can be significant in the context of <SPAN
CLASS="PRODUCTNAME"
>eCos</SPAN
> savefiles.
For instance, consider the following configuration option:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD