URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [language.values.html] - Rev 593
Go to most recent revision | Compare with Previous | Blame | View Log
<!-- Copyright (C) 2003 Red Hat, Inc. --> <!-- This material may be distributed only subject to the terms --> <!-- and conditions set forth in the Open Publication License, v1.0 --> <!-- or later (the latest version is presently available at --> <!-- http://www.opencontent.org/openpub/). --> <!-- Distribution of the work or derivative of the work in any --> <!-- standard (paper) book form is prohibited unless prior --> <!-- permission is obtained from the copyright holder. --> <HTML ><HEAD ><TITLE >Values and Expressions</TITLE ><meta name="MSSmartTagsPreventParsing" content="TRUE"> <META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ "><LINK REL="HOME" TITLE="The eCos Component Writer's Guide" HREF="cdl-guide.html"><LINK REL="UP" TITLE="The CDL Language" HREF="language.html"><LINK REL="PREVIOUS" TITLE="An Introduction to Tcl" HREF="language.tcl.html"><LINK REL="NEXT" TITLE="Interfaces" HREF="language.interface.html"></HEAD ><BODY CLASS="SECT1" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >The <SPAN CLASS="APPLICATION" >eCos</SPAN > Component Writer's Guide</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="language.tcl.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" >Chapter 3. The CDL Language</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="language.interface.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="LANGUAGE.VALUES">Values and Expressions</H1 ><P >It is fairly reasonable to expect that enabling or disabling a configuration option such as <TT CLASS="VARNAME" >CYGVAR_KERNEL_THREADS_DATA</TT > in some way affects its <SPAN CLASS="emphasis" ><I CLASS="EMPHASIS" >value</I ></SPAN >. This will have an effect on any expressions that reference this option such as <TT CLASS="LITERAL" >requires CYGVAR_KERNEL_THREADS_DATA</TT >. It will also affect the consequences of that option: how it affects the build process and what happens to any constraints that <TT CLASS="VARNAME" >CYGVAR_KERNEL_THREADS_DATA</TT > may impose (as opposed to constraints on this option imposed by others).</P ><P >In a language like C the handling of variables is relatively straightforward. If a variable <TT CLASS="VARNAME" >x</TT > gets referenced in an expression such as <TT CLASS="LITERAL" >if (x != 0)</TT >, and that variable is not defined anywhere, then the code will fail to build, typically with an unresolved error at link-time. Also in C a variable <TT CLASS="VARNAME" >x</TT > does not live in any hierarchy, so its value for the purposes of expression evaluation is not affected by anything else. C variables also have a clear type such as <TT CLASS="LITERAL" >int</TT > or <TT CLASS="LITERAL" >long double</TT >. </P ><P >In <SPAN CLASS="APPLICATION" >CDL</SPAN > things are not so straightforward.</P ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LANGUAGE.VALUES.VALUE">Option Values</H2 ><P >There are four factors which go into an option's value:</P ><P ></P ><OL TYPE="1" ><LI ><P >An option may or may not be loaded.</P ></LI ><LI ><P >If the option is loaded, it may or may not be active.</P ></LI ><LI ><P >Even if the option is active, it may or may not be enabled.</P ></LI ><LI ><P >If the option is loaded, active and enabled then it will have some associated data which constitutes its value.</P ></LI ></OL ><DIV CLASS="SECT3" ><H3 CLASS="SECT3" ><A NAME="LANGUAGE.VALUES.VALUE.LOADED">Is the Option Loaded?</H3 ><P >At any one time a configuration will contain only a subset of all possible packages. In fact it is impossible to combine certain packages in a single configuration. For example architectural HAL packages should contain a set of options defining endianness, the sizes of basic data types and so on (many of which will of course be constant for any given architecture). Any attempt to load two architectural HAL packages into a configuration will fail because of the resulting name clash. Since <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions can reference options in other packages, and often need to do so, it is essential to define the resulting behavior.</P ><P >One complication is that the component framework does not know about every single option in every single package. Obviously it cannot know about packages from arbitrary third parties which have not been installed. Even for packages which have been installed, the current repository database does not hold details of every option, only of the packages themselves. If a <SPAN CLASS="APPLICATION" >CDL</SPAN > expression contains a reference to some option <TT CLASS="VARNAME" >CYGSEM_KERNEL_SCHED_TIMESLICE</TT > then the component framework will only know about this option if the kernel package is actually loaded into the current configuration. If the package is not loaded then theoretically the framework might guess that the option is somehow related to the kernel by examining the option name but this would not be robust: the option could easily be part of some other package that violates the naming convention.</P ><P >Assume that the user is building a minimal configuration which does not contain the kernel package, but does have other packages which contain the following constraints:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires CYGPKG_KERNEL requires CYGPKG_KERNEL_THREADS_DATA requires !CYGSEM_KERNEL_SCHED_TIMESLICE</PRE ></TD ></TR ></TABLE ><P >Clearly the first constraint is not satisfied because the kernel is not loaded. The second constraint is also not satisfied. The third constraint is trivially satisfied: if there is no kernel then the kernel's timeslicing support cannot possibly be enabled. </P ><P >Any options which are not in the current configuration are handled as follows: </P ><P ></P ><OL TYPE="1" ><LI ><P >Any references to that option will evaluate to <TT CLASS="LITERAL" >0</TT >, so <TT CLASS="LITERAL" >requires !CYGSEM_KERNEL_SCHED_TIMESLICE</TT > will be satisfied but <TT CLASS="LITERAL" >requires CYGSEM_KERNEL_THREADS_DATA</TT > will not be satisfied.</P ></LI ><LI ><P >An option that is not loaded has no consequences on the build process. It cannot directly result in any <TT CLASS="LITERAL" >#define's</TT > in a configuration header file, nor in any files being compiled. This is only reasonable: if the option is not loaded then the component framework has no way of knowing about any <SPAN CLASS="PROPERTY" >compile</SPAN > or similar properties. An option that is not loaded can have indirect consequences by being referenced in <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions.</P ></LI ><LI ><P >An option that is not loaded cannot impose any constraints on the rest of the configuration. Again this is the only reasonable behavior: if the option is not loaded then any associated <SPAN CLASS="PROPERTY" >requires</SPAN > or <SPAN CLASS="PROPERTY" >legal_values</SPAN > properties will not be known.</P ></LI ></OL ></DIV ><DIV CLASS="SECT3" ><H3 CLASS="SECT3" ><A NAME="LANGUAGE.VALUES.VALUE.ACTIVE">Is the Option Active</H3 ><P >The next issue to consider is whether or not a particular option is active. Configuration options are organized in a hierarchy of components and sub-components. For example the C library package contains a component <TT CLASS="VARNAME" >CYGPKG_LIBC_STDIO</TT > containing all the options related to standard I/O. If a user disables the component as a whole then all the options below it become inactive: it makes no sense to disable all stdio functionality and then manipulate the buffer sizes.</P ><P >Inactive is not quite the same as disabled, although the effects are similar. The value of an inactive option is preserved. If the user modifies a buffer size option, then disables the whole stdio component, the buffer size value remains in case the stdio component is re-enabled later on. Some tools such as the graphical configuration tool will treat inactive options specially, for example such options may be grayed out.</P ><P >The active or inactive state of an option may affect other packages. For example a package may use the <TT CLASS="FUNCTION" >sprintf</TT > function and require support for floating point conversions, a constraint that is not satisfied if the relevant option is inactive. It is necessary to define exactly what it means for an option to be inactive:</P ><P ></P ><OL TYPE="1" ><LI ><P >An option is inactive if its parent is either inactive or disabled. For example if <TT CLASS="VARNAME" >CYGPKG_LIBC_STDIO</TT > is disabled then all the options and sub-components become inactive; since <TT CLASS="VARNAME" >CYGPKG_LIBC_STDIO_FLOATING_POINT</TT > is now inactive, <TT CLASS="VARNAME" >CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT > is inactive as well.</P ></LI ><LI ><P >Options may also be inactive as a result of an <SPAN CLASS="PROPERTY" >active_if</SPAN > property. This is useful if a particular option is only relevant if two or more disjoint sets of conditions need to be satisfied, since the hierarchical structure can only cope with at most one such set.</P ></LI ><LI ><P >If an option is inactive then any references to that option in <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions will evaluate to <TT CLASS="LITERAL" >0</TT >. Hence a constraint of the form <TT CLASS="LITERAL" >requires CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT > is not satisfied if the entire stdio component is disabled.</P ></LI ><LI ><P >An option that is inactive has no consequences on the build process. No <TT CLASS="LITERAL" >#define</TT > will be generated. Any <SPAN CLASS="PROPERTY" >compile</SPAN > or similar properties will be ignored.</P ></LI ><LI ><P >An option that is inactive cannot impose any constraints on the rest of the configuration. For example <TT CLASS="VARNAME" >CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT > has a dependency <TT CLASS="LITERAL" >requires CYGPKG_LIBM</TT >, but if all of the stdio functionality is disabled then this constraint is ignored (although of course there may be other packages which have a dependency on <TT CLASS="VARNAME" >CYGPKG_LIBM</TT >.</P ></LI ></OL ></DIV ><DIV CLASS="SECT3" ><H3 CLASS="SECT3" ><A NAME="LANGUAGE.VALUES.VALUE.ENABLED">Is the Option Enabled? What is the Data?</H3 ><P >The majority of configuration options are boolean in nature, so the user can either enable or disable some functionality. Some options are different. For example <TT CLASS="VARNAME" >CYGNUM_LIBC_STDIO_BUFSIZE</TT > is a number, and <TT CLASS="VARNAME" >CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE</TT > is a string corresponding to a device name. A few options like <TT CLASS="VARNAME" >CYGDAT_UITRON_TASK_EXTERNS</TT > can get very complicated. <SPAN CLASS="APPLICATION" >CDL</SPAN > has to cope with this variety, and define the exact behavior of the system in terms of constraints and build-time consequences. </P ><P >In <SPAN CLASS="APPLICATION" >CDL</SPAN > the value of an option consists of two parts. There is a boolean part, controlling whether or not the option is enabled. There is also a data part, providing additional information. For most options one of these parts is fixed, as controlled by the option's <SPAN CLASS="PROPERTY" >flavor</SPAN > property:</P ><DIV CLASS="INFORMALTABLE" ><A NAME="AEN1413"><P ></P ><TABLE BORDER="1" CLASS="CALSTABLE" ><THEAD ><TR ><TH ALIGN="LEFT" VALIGN="TOP" >Flavor</TH ><TH ALIGN="LEFT" VALIGN="TOP" >Enabled</TH ><TH ALIGN="LEFT" VALIGN="TOP" >Data</TH ></TR ></THEAD ><TBODY ><TR ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >none</TT ></TD ><TD ALIGN="LEFT" VALIGN="TOP" >Always enabled</TD ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >1</TT >, not modifiable</TD ></TR ><TR ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >bool</TT ></TD ><TD ALIGN="LEFT" VALIGN="TOP" >User-modifiable</TD ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >1</TT >, not modifiable</TD ></TR ><TR ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >data</TT ></TD ><TD ALIGN="LEFT" VALIGN="TOP" >Always enabled</TD ><TD ALIGN="LEFT" VALIGN="TOP" >User-modifiable</TD ></TR ><TR ><TD ALIGN="LEFT" VALIGN="TOP" ><TT CLASS="LITERAL" >booldata</TT ></TD ><TD ALIGN="LEFT" VALIGN="TOP" >User-modifiable</TD ><TD ALIGN="LEFT" VALIGN="TOP" >User-modifiable</TD ></TR ></TBODY ></TABLE ><P ></P ></DIV ><P >The effects of the boolean and data parts are as follows:</P ><P ></P ><OL TYPE="1" ><LI ><P >If an option is disabled, in other words if the boolean part is false, then any references to that option in <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions will evaluate to <TT CLASS="LITERAL" >0</TT >. This is the same behavior as for inactive options. The data part is not relevant. The <TT CLASS="LITERAL" >none</TT > and <TT CLASS="LITERAL" >data</TT > flavors specify that the option is always enabled, in which case this rule is not applicable.</P ></LI ><LI ><P >If an option is enabled then any references to that option in <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions will evaluate to the option's data part. For two of the flavors, <TT CLASS="LITERAL" >none</TT > and <TT CLASS="LITERAL" >bool</TT >, this data part is fixed to the constant <TT CLASS="LITERAL" >1</TT > which generally has the expected result.</P ></LI ><LI ><P >If a component or package is disabled then all sub-components and options immediately below it in the hierarchy are inactive. By a process of recursion this will affect all the nodes in the subtree.</P ></LI ><LI ><P >If an option is disabled then it can impose no constraints on the rest of the configuration, in particular <SPAN CLASS="PROPERTY" >requires</SPAN > and <SPAN CLASS="PROPERTY" >legal_values</SPAN > properties will be ignored. If an option is enabled then its constraints should be satisfied, or the component framework will report various conflicts. Note that the <SPAN CLASS="PROPERTY" >legal_values</SPAN > constraint only applies to the data part of the option's value, so it is only useful with the <TT CLASS="LITERAL" >data</TT > and <TT CLASS="LITERAL" >booldata</TT > flavors. Options with the <TT CLASS="LITERAL" >none</TT > and <TT CLASS="LITERAL" >data</TT > flavors are always enabled so their constraints always have to be satisfied (assuming the option is active). </P ></LI ><LI ><P >If an option is disabled then it has no direct consequences at build-time: no <TT CLASS="LITERAL" >#define</TT > will be generated, no files will get compiled, and so on. If an option is active and enabled then all the consequences take effect. The option name and data part are used to generate the <TT CLASS="LITERAL" >#define</TT > in the appropriate configuration header file, subject to various properties such as <SPAN CLASS="PROPERTY" >no_define</SPAN >, but the data part has no other effects on the build system. </P ></LI ></OL ><P >By default all options and components have the <TT CLASS="LITERAL" >bool</TT > flavor: most options are boolean in nature, so making this the default allows for slightly more compact <SPAN CLASS="APPLICATION" >CDL</SPAN > scripts. Packages have the <TT CLASS="LITERAL" >booldata</TT > flavor, where the data part always corresponds to the version of the package that is loaded into the configuration: changing this value corresponds to unloading the old version and loading in a different one.</P ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B ><SPAN CLASS="APPLICATION" >CDL</SPAN > Flavors: </B >The concept of <SPAN CLASS="APPLICATION" >CDL</SPAN > flavors tends to result in various discussions about why it is unnecessarily complicated, and would it not have been easier to do … However there are very good reasons why CDL works the way it does.</P ><P >The first common suggestion is that there is no need to have separate flavors <TT CLASS="LITERAL" >bool</TT >, <TT CLASS="LITERAL" >data</TT >, and so on. A boolean option could just be handled as a data option with legal values <TT CLASS="LITERAL" >0</TT > and <TT CLASS="LITERAL" >1</TT >. The counter arguments are as follows:</P ><P ></P ><OL TYPE="1" ><LI ><P >It would actually make <SPAN CLASS="APPLICATION" >CDL</SPAN > scripts more verbose. By default all options and components have the <TT CLASS="LITERAL" >bool</TT > flavor, since most options are boolean in nature. Without a <TT CLASS="LITERAL" >bool</TT > flavor it would be necessary to indicate explicitly what the legal values are somehow, e.g. with a <SPAN CLASS="PROPERTY" >legal_values</SPAN > property.</P ></LI ><LI ><P >The boolean part of an option's value has a very different effect from the data part. If an option is disabled then it has no consequences at build time, and can impose no constraints. A <TT CLASS="LITERAL" >data</TT > option always has consequences and can impose constraints. To get the desired effect it would be necessary to add <SPAN CLASS="APPLICATION" >CDL</SPAN > data indicating that a value of <TT CLASS="LITERAL" >0</TT > should be treated specially. Arguably this could be made built-in default behavior, although that would complicate options where <TT CLASS="LITERAL" >0</TT > is a perfectly legal number, for example <TT CLASS="VARNAME" >CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET</TT >. </P ></LI ><LI ><P >There would no replacement for a <TT CLASS="LITERAL" >booldata</TT > option for which <TT CLASS="LITERAL" >0</TT > is a valid value. Again some additional <SPAN CLASS="APPLICATION" >CDL</SPAN > syntax would be needed to express such a concept.</P ></LI ></OL ><P >Although initially it may seem confusing that an option's value has both a boolean and a data part, it is an accurate reflection of how configuration options actually work. The various alternatives would all make it harder to write <SPAN CLASS="APPLICATION" >CDL</SPAN > scripts.</P ><P >The next common suggestion is that the data part of a value should be typed in much the same way as C or C++ data types. For example it should be possible to describe <TT CLASS="VARNAME" >CYGNUM_LIBC_STDIO_BUFSIZE</TT > as an integer value, rather than imposing <SPAN CLASS="PROPERTY" >legal_values</SPAN > constraints. Again there are very good reasons why this approach was not taken:</P ><P ></P ><OL TYPE="1" ><LI ><P >The possible legal values for an integer are rarely correct for a <SPAN CLASS="APPLICATION" >CDL</SPAN > option. A constraint such as <TT CLASS="LITERAL" >1 to 0x7fffffff</TT > is a bit more accurate, although if this option indicates a buffer size it is still not particularly good — very few targets will have enough memory for such a buffer. Forcing <SPAN CLASS="APPLICATION" >CDL</SPAN > writers to list the <SPAN CLASS="PROPERTY" >legal_values</SPAN > constraints explicitly should make them think a bit more about what values are actually sensible. For example <TT CLASS="VARNAME" >CYGNUM_LIBC_TIME_DST_DEFAULT_OFFSET</TT > has legal values in the range <TT CLASS="LITERAL" >-90000 to 90000</TT >, which helps the user to set a sensible value.</P ></LI ><LI ><P >Not all options correspond to simple data types such as integers. <TT CLASS="VARNAME" >CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE</TT > is a C string, and would have to be expressed using something like <TT CLASS="LITERAL" >char []</TT >. This introduces plenty of opportunities for confusion, especially since square brackets may get processed by the <SPAN CLASS="APPLICATION" >Tcl</SPAN > interpreter for command substitution.</P ></LI ><LI ><P >Some configuration options can get very complicated indeed, for example the default value of <TT CLASS="VARNAME" >CYGDAT_UITRON_TASK_INITIALIZERS</TT > is:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" >CYG_UIT_TASK( "t1", 1, task1, &stack1, CYGNUM_UITRON_STACK_SIZE ), \ CYG_UIT_TASK( "t2", 2, task2, &stack2, CYGNUM_UITRON_STACK_SIZE ), \ CYG_UIT_TASK( "t3", 3, task3, &stack3, CYGNUM_UITRON_STACK_SIZE ), \ CYG_UIT_TASK( "t4", 4, task4, &stack4, CYGNUM_UITRON_STACK_SIZE )</PRE ></TD ></TR ></TABLE ><P >This would require <SPAN CLASS="APPLICATION" >CDL</SPAN > knowing about C macros, structures, arrays, static initializers, and so on. Adding such detailed knowledge about the C language to the component framework is inappropriate.</P ></LI ><LI ><P ><SPAN CLASS="APPLICATION" >CDL</SPAN > needs to be usable with languages other than C. At present this includes C++, in future it may include languages such as Java. Each language adds new data types and related complications, for example C++ classes and inheritance. Making <SPAN CLASS="APPLICATION" >CDL</SPAN > support a union of all data types in all possible languages is not sensible.</P ></LI ></OL ><P >The <SPAN CLASS="APPLICATION" >CDL</SPAN > approach of treating all data as a sequence of characters, possibly constrained by a <SPAN CLASS="PROPERTY" >legal_values</SPAN > property or other means, has the great advantage of simplicity. It also fits in with the <SPAN CLASS="APPLICATION" >Tcl</SPAN > language that underlies <SPAN CLASS="APPLICATION" >CDL</SPAN >.</P ></BLOCKQUOTE ></DIV ></DIV ><DIV CLASS="SECT3" ><H3 CLASS="SECT3" ><A NAME="LANGUAGE.VALUES.VALUE.EXAMPLES">Some Examples</H3 ><P >The following excerpt from the C library's <SPAN CLASS="APPLICATION" >CDL</SPAN > scripts can be used to illustrate how values and flavors work in practice:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" >cdl_component CYGPKG_LIBC_RAND { flavor none compile stdlib/rand.cxx cdl_option CYGSEM_LIBC_PER_THREAD_RAND { requires CYGVAR_KERNEL_THREADS_DATA default_value 0 } cdl_option CYGNUM_LIBC_RAND_SEED { flavor data legal_values 0 to 0x7fffffff default_value 1 } cdl_option CYGNUM_LIBC_RAND_TRACE_LEVEL { flavor data legal_values 0 to 1 default_value 0 } }</PRE ></TD ></TR ></TABLE ><P >If the application does not require any C library functionality then it is possible to have a configuration where the C library is not loaded. This can be achieved by starting with the minimal template, or by starting with another template such as the default one and then explicitly unloading the C library package. If this package is not loaded then any references to the <TT CLASS="VARNAME" >CYGPKG_LIBC_RAND</TT > component or any of its options will have a value of <TT CLASS="LITERAL" >0</TT > for the purposes of expression evaluation. No <TT CLASS="LITERAL" >#define's</TT > will be generated for the component or any of its options, and the file <TT CLASS="FILENAME" >stdlib/rand.cxx</TT > will not get compiled. There is nothing special about the C library here, exactly the same would apply for say a device driver that does not correspond to any of the devices on the target hardware.</P ><P >Assuming the C library is loaded, the next thing to consider is whether or not the component and its options are active. The component is layered immediately below the C library package itself, so if the package is loaded then it is safe to assume that the package is also enabled. Therefore the parent of <TT CLASS="VARNAME" >CYGPKG_LIBC_RAND</TT > is active and enabled, and in the absence of any <SPAN CLASS="PROPERTY" >active_if</SPAN > properties <TT CLASS="VARNAME" >CYGPKG_LIBC_RAND</TT > will be active as well.</P ><P >The component <TT CLASS="VARNAME" >CYGPKG_LIBC_RAND</TT > has the flavor <TT CLASS="LITERAL" >none</TT >. This means the component cannot be disabled. Therefore all the options in this component have an active and enabled parent, and in the absence of any <SPAN CLASS="PROPERTY" >active_if</SPAN > properties they are all active as well.</P ><P >The component's flavor <TT CLASS="LITERAL" >none</TT > serves to group together all of the configuration options related to random number generation. This is particularly useful in the context of the graphical configuration tool, but it also helps when it comes to naming the options: all of the options begin with <TT CLASS="LITERAL" >CYGxxx_LIBC_RAND</TT >, giving a clear hint about both the package and the component within that package. The flavor means that the component is always enabled and has the value <TT CLASS="LITERAL" >1</TT > for the purposes of expression evaluation. There will always be a single <TT CLASS="LITERAL" >#define</TT > of the form:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" >#define CYGPKG_LIBC_RAND 1</PRE ></TD ></TR ></TABLE ><P >In addition the file <TT CLASS="FILENAME" >stdlib/rand.cxx</TT > will always get built. If the component had the default <TT CLASS="LITERAL" >bool</TT > flavor then users would be able to disable the whole component, and one less file would need to be built. However random number generation is relatively simple, so the impact on eCos build times are small. Furthermore by default the code has no dependencies on other parts of the system, so compiling the code has no unexpected side effects. Even if it was possible to disable the component, the sensible default for most applications would still leave it enabled. The net result is that the flavor <TT CLASS="LITERAL" >none</TT > is probably the most sensible one for this component. For other components the default <TT CLASS="LITERAL" >bool</TT > flavor or one of the other flavors might be more appropriate.</P ><P >Next consider option <TT CLASS="VARNAME" >CYGSEM_LIBC_PER_THREAD_RAND</TT > which can be used to get a per-thread random number seed, possibly useful if the application needs a consistent sequence of random numbers. In the absence of a <SPAN CLASS="PROPERTY" >flavor</SPAN > property this option will be boolean, and the <SPAN CLASS="PROPERTY" >default_value</SPAN > property means that it is disabled by default — reasonable since few applications need this particular functionality, and it does impose a constraint on the rest of the system. If the option is left disabled then no <TT CLASS="LITERAL" >#define</TT > will be generated, and if there were any <SPAN CLASS="PROPERTY" >compile</SPAN > or similar properties these would not take effect. If the option is enabled then a <TT CLASS="LITERAL" >#define</TT > will be generated, using the option's data part which is fixed at <TT CLASS="LITERAL" >1</TT >:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" >#define CYGSEM_LIBC_PER_THREAD_RAND 1</PRE ></TD ></TR ></TABLE ><P >The <TT CLASS="VARNAME" >CYGSEM_LIBC_PER_THREAD_RAND</TT > option has a <SPAN CLASS="PROPERTY" >requires</SPAN > constraint on <TT CLASS="VARNAME" >CYGVAR_KERNEL_THREADS_DATA</TT >. If the C library option is enabled then the constraint should be satisfied, or else the configuration contains a conflict. If the configuration does not include the kernel package then <TT CLASS="VARNAME" >CYGVAR_KERNEL_THREADS_DATA</TT > will evaluate to <TT CLASS="LITERAL" >0</TT > and the constraint is not satisfied. Similarly if the option is inactive or disabled the constraint will not be satisfied.</P ><P ><TT CLASS="VARNAME" >CYGNUM_LIBC_RAND_SEED</TT > and <TT CLASS="VARNAME" >CYGNUM_LIBC_RAND_TRACE_LEVEL</TT > both have the <TT CLASS="LITERAL" >data</TT > flavor, so they are always enabled and the component framework will generate appropriate <TT CLASS="LITERAL" >#define's</TT >:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" >#define CYGNUM_LIBC_RAND_SEED 1 #define CYGNUM_LIBC_RAND_SEED_1 #define CYGNUM_LIBC_RAND_TRACE_LEVEL 0 #define CYGNUM_LIBC_RAND_TRACE_LEVEL_0</PRE ></TD ></TR ></TABLE ><P >Neither option has a <SPAN CLASS="PROPERTY" >compile</SPAN > or similar property, but any such properties would take effect. Any references to these options in <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions would evaluate to the data part, so a hypothetical constraint of the form <TT CLASS="LITERAL" >{ requires CYGNUM_LIBC_RAND_SEED > 42 }</TT > would not be satisfied with the default values. Both options use a simple constant for the <SPAN CLASS="PROPERTY" >default_value</SPAN > expression. It would be possible to use a more complicated expression, for example the default for <TT CLASS="VARNAME" >CYGNUM_LIBC_RAND_TRACE_LEVEL</TT > could be determined from some global debugging option or from a debugging option that applies to the C library as a whole. Both options also have a <SPAN CLASS="PROPERTY" >legal_values</SPAN > constraint, which must be satisfied since the options are active and enabled. </P ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B >Note: </B >The value <TT CLASS="LITERAL" >0</TT > is legal for both <TT CLASS="VARNAME" >CYGNUM_LIBC_RAND_SEED</TT > and <TT CLASS="VARNAME" >CYGNUM_LIBC_RAND_TRACE_LEVEL</TT >, so in a <SPAN CLASS="APPLICATION" >CDL</SPAN > expression there is no easy way of distinguishing between the options being absent or having that particular value. This will be addressed by future enhancements to the expression syntax.</P ></BLOCKQUOTE ></DIV ></DIV ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LANGUAGE.EXPRESSION">Ordinary Expressions</H2 ><P >Expressions in <SPAN CLASS="APPLICATION" >CDL</SPAN > follow a conventional syntax, for example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > default_value CYGGLO_CODESIZE > CYGGLO_SPEED default_value { (CYG_HAL_STARTUP == "RAM" && !CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS && !CYGINT_HAL_USE_ROM_MONITOR_UNSUPPORTED && !CYGSEM_HAL_POWERPC_COPY_VECTORS) ? 1 : 0 } default_value { "\"/dev/ser0\"" }</PRE ></TD ></TR ></TABLE ><P >However there is a complication in that the various arguments to a <SPAN CLASS="PROPERTY" >default_value</SPAN > property will first get processed by a <SPAN CLASS="APPLICATION" >Tcl</SPAN > interpreter, so special characters like quotes and square brackets may get processed. Such problems can be avoided by enclosing non-trivial expressions in braces, as in the second example above. The way expression parsing actually works is as follows:</P ><P ></P ><OL TYPE="1" ><LI ><P >The <SPAN CLASS="APPLICATION" >Tcl</SPAN > interpreter splits the line or lines into a command and its arguments. In the first <SPAN CLASS="PROPERTY" >default_value</SPAN > expression above the command is <TT CLASS="LITERAL" >default_value</TT > and there are three arguments, <TT CLASS="LITERAL" >CYGGLO_CODESIZE</TT >, <TT CLASS="LITERAL" >></TT > and <TT CLASS="LITERAL" >CYGGLO_SPEED</TT >. In the second and third examples there is just one argument, courtesy of the braces.</P ></LI ><LI ><P >Next option processing takes place, so any initial arguments that begin with a hyphen will be interpreted as options. This can cause problems if the expression involves a negative number, so the special argument <TT CLASS="LITERAL" >--</TT > can be used to prevent option processing on the subsequent arguments.</P ></LI ><LI ><P >All of the arguments are now concatenated, with a single space in between each one. Hence the following two expressions are equivalent, even though they will have been processed differently up to this point.</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > default_value CYGGLO_CODESIZE > CYGGLO_SPEED default_value {CYGGLO_CODESIZE > CYGGLO_SPEED}</PRE ></TD ></TR ></TABLE ></LI ><LI ><P >The expression parsing code now has a single string to process.</P ></LI ></OL ><P ><SPAN CLASS="APPLICATION" >CDL</SPAN > expressions consist of four types of element: references to configuration options, constant strings, integers, and floating point numbers. These are combined using a conventional set of operators: the unary operators <TT CLASS="LITERAL" >-</TT >, <TT CLASS="LITERAL" >~</TT > and <TT CLASS="LITERAL" >!</TT >; the arithmetic operators <TT CLASS="LITERAL" >+</TT >, <TT CLASS="LITERAL" >-</TT >, <TT CLASS="LITERAL" >*</TT >, <TT CLASS="LITERAL" >/</TT > and <TT CLASS="LITERAL" >%</TT >; the shift operators <TT CLASS="LITERAL" ><<</TT > and <TT CLASS="LITERAL" >>></TT >; the comparison operators <TT CLASS="LITERAL" >==</TT >, <TT CLASS="LITERAL" >!=</TT >, <TT CLASS="LITERAL" ><</TT >, <TT CLASS="LITERAL" ><=</TT >, <TT CLASS="LITERAL" >></TT > and <TT CLASS="LITERAL" >>=</TT >; the bitwise operators <TT CLASS="LITERAL" >&</TT >, <TT CLASS="LITERAL" >^</TT > and <TT CLASS="LITERAL" >|</TT >; the logical operators <TT CLASS="LITERAL" >&&</TT > and <TT CLASS="LITERAL" >||</TT >; the string concatenation operator <TT CLASS="LITERAL" >.</TT >; and the ternary conditional operator <TT CLASS="LITERAL" >A ? B : C</TT >. There is also support for some less widely available operators for logical equivalence and implication, and for a set of function-style operations. Bracketed sub-expressions are supported, and the operators have the usual precedence:</P ><DIV CLASS="INFORMALTABLE" ><A NAME="AEN1653"><P ></P ><TABLE BORDER="1" CLASS="CALSTABLE" ><THEAD ><TR ><TH WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >Priority</TH ><TH WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >Operators</TH ><TH WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >Category</TH ></TR ></THEAD ><TBODY ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >16</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >references, constants</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >basic elements</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >15</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >f(a, b, c)</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >function calls</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >14</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >~</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >bitwise not</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >14</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >!</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >logical not</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >14</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >-</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >arithmetic negation</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >13</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >* / %</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >multiplicative arithmetic</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >12</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >+ - .</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >additive arithmetic and string concatenation</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >11</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" ><< >></TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >bitwise shifts</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >10</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" ><= < > >=</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >inequality</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >9</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >== !=</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >comparison</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >8</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >&</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >bitwise and</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >7</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >^</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >bitwise xor</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >6</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >|</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >bitwise or</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >5</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >&&</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >logical and</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >4</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >||</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >logical or</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >3</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >xor, eqv</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >logical equivalance</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >2</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >implies</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >logical implication</TD ></TR ><TR ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >1</TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" ><TT CLASS="LITERAL" >? :</TT ></TD ><TD WIDTH="33%" ALIGN="CENTER" VALIGN="TOP" >conditional</TD ></TR ></TBODY ></TABLE ><P ></P ></DIV ><P >Function calls have the usual format of a name, an opening bracket, one or more arguments separated by commas, and a closing bracket. For example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, " -fno-rtti") }</PRE ></TD ></TR ></TABLE ><P >Functions will differ in the number of arguments and may impose restrictions on some or all of their arguments. For example it may be necessary for the first argument to be a reference to a configuration option. The available functions are described in <A HREF="language.values.html#LANGUAGE.FUNCTIONS" >the Section called <I >Functions</I ></A >. </P ><P >The logical <TT CLASS="LITERAL" >xor</TT > operator evaluates to true if either the left hand side or the right hand side but not both evaluate to true The logical <TT CLASS="LITERAL" >eqv</TT > operator evaluates to true if both the left and right hand sides evaluate to true, or if both evaluate to false. The <TT CLASS="LITERAL" >implies</TT > operator evaluates to true either if the left hand side is false or if the right hand side is true, in other words <TT CLASS="LITERAL" >A implies B</TT > has the same meaning as <TT CLASS="LITERAL" >!A || B</TT >. An example use would be:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { is_active(CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE) implies (CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE >= (16 * 1024)) }</PRE ></TD ></TR ></TABLE ><P >This constraint would be satisfied if either the support for a main stack size is disabled, or if that stack is at least 16K. However if such a stack were in use but was too small, a conflict would be raised.</P ><P >A valid <SPAN CLASS="APPLICATION" >CDL</SPAN > identifier in an expression, for example <TT CLASS="VARNAME" >CYGGLO_SPEED</TT >, will be interpreted as a reference to a configuration option by that name. The option does not have to be loaded into the current configuration. When the component framework evaluates the expression it will substitute in a suitable value that depends on whether or not the option is loaded, active, and enabled. The exact rules are described in <A HREF="language.values.html#LANGUAGE.VALUES.VALUE" >the Section called <I >Option Values</I ></A >.</P ><P >A constant string is any sequence of characters enclosed in quotes. Care has to be taken that these quotes are not stripped off by the <SPAN CLASS="APPLICATION" >Tcl</SPAN > interpreter before the <SPAN CLASS="APPLICATION" >CDL</SPAN > expression parser sees them. Consider the following:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > default_value "RAM"</PRE ></TD ></TR ></TABLE ><P >The quote marks will be stripped before the <SPAN CLASS="APPLICATION" >CDL</SPAN > expression parser sees the data, so the expression will be interpreted as a reference to a configuration option <TT CLASS="VARNAME" >RAM</TT >. There is unlikely to be such an option, so the actual default value will be <TT CLASS="LITERAL" >0</TT >. Careful use of braces or other <SPAN CLASS="APPLICATION" >Tcl</SPAN > quoting mechanisms can be used to avoid such problems.</P ><P > String constants consist of the data inside the quotes. If the data itself needs to contain quote characters then appropriate quoting is again necessary, for example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > default_value { "\"/dev/ser0\"" }</PRE ></TD ></TR ></TABLE ><P >An integer constant consists of a sequence of digits, optionally preceeded with the unary <TT CLASS="LITERAL" >+</TT > or <TT CLASS="LITERAL" >-</TT > operators. As usual the sequence <TT CLASS="LITERAL" >0x</TT > or <TT CLASS="LITERAL" >0X</TT > can be used for hexadecimal data, and a leading <TT CLASS="LITERAL" >0</TT > indicates octal data. Internally the component framework uses 64-bit arithmetic for integer data. If a constant is too large then double precision arithmetic will be used instead. Traditional syntax is also used for double precision numbers, for example <TT CLASS="LITERAL" >3.141592</TT > or <TT CLASS="LITERAL" >-3E6</TT >. </P ><P >Of course this is not completely accurate: <SPAN CLASS="APPLICATION" >CDL</SPAN > is not a typed language, all data is treated as if it were a string. For example the following two lines are equivalent:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires CYGNUM_UITRON_SEMAS > 10 requires { CYGNUM_UITRON_SEMAS > "10" }</PRE ></TD ></TR ></TABLE ><P >When an expression gets evaluated the operators will attempt appropriate conversions. The <TT CLASS="LITERAL" >></TT > comparison operator can be used on either integer or double precision numbers, so it will begin by attempting a string to integer conversion of both operands. If that fails it will attempt string to double conversions. If that fails as well then the component framework will report a conflict, an evaluation exception. If the conversions from string to integer are successful then the result will be either the string <TT CLASS="LITERAL" >0</TT > or the string <TT CLASS="LITERAL" >1</TT >, both of which can be converted to integers or doubles as required.</P ><P >It is worth noting that the expression <TT CLASS="LITERAL" >CYGNUM_UITRON_SEMAS >10</TT > is not ambiguous. <SPAN CLASS="APPLICATION" >CDL</SPAN > identifiers can never begin with a digit, so it is not possible for <TT CLASS="LITERAL" >10</TT > to be misinterpreted as a reference to an identifier instead of as a string.</P ><P >Of course the implementation is slightly different again. The <SPAN CLASS="APPLICATION" >CDL</SPAN > language definition is such that all data is treated as if it were a string, with conversions to integer, double or boolean as and when required. The implementation is allowed to avoid conversions until they are necessary. For example, given <TT CLASS="LITERAL" >CYGNUM_UITRON_SEMAS > 10</TT > the expression parsing code will perform an immediate conversion from string to integer, storing the integer representation, and there is no need for a conversion by the comparison operator when the expression gets evaluated. Given <TT CLASS="LITERAL" >{ CYGNUM_UITRON_SEMAS > "10" }</TT > the parsing code will store the string representation and a conversion happens the first time the expression is evaluated. All of this is an implementation detail, and does not affect the semantics of the language. </P ><P >Different operators have different requirements, for example the bitwise or operator only makes sense if both operands have an integer representation. For operators which can work with either integer or double precision numbers, integer arithmetic will be preferred.</P ><P >The following operators only accept integer operands: unary <TT CLASS="LITERAL" >~</TT > (bitwise not), the shift operators <TT CLASS="LITERAL" ><<</TT > and <TT CLASS="LITERAL" >>></TT >, and the bitwise operators <TT CLASS="LITERAL" >&</TT >, <TT CLASS="LITERAL" >|</TT > and <TT CLASS="LITERAL" >^</TT >.</P ><P >The following operators will attempt integer arithmetic first, then double precision arithmetic: unary <TT CLASS="LITERAL" >-</TT >, the arithmetic operators <TT CLASS="LITERAL" >+</TT >, <TT CLASS="LITERAL" >-</TT >, <TT CLASS="LITERAL" >*</TT >, <TT CLASS="LITERAL" >/</TT >, and <TT CLASS="LITERAL" >%</TT >; and the comparision operators <TT CLASS="LITERAL" ><</TT >, <TT CLASS="LITERAL" ><=</TT >, <TT CLASS="LITERAL" >></TT > and <TT CLASS="LITERAL" >>=</TT >. </P ><P >The equality <TT CLASS="LITERAL" >==</TT > and inequality <TT CLASS="LITERAL" >!=</TT > operators will first attempt integer conversion and comparison. If that fails then double precision will be attempted (although arguably using these operators on double precision data is not sensible). As a last resort string comparison will be used.</P ><P >The operators <TT CLASS="LITERAL" >!</TT >, <TT CLASS="LITERAL" >&&</TT > and <TT CLASS="LITERAL" >||</TT > all work with boolean data. Any string that can be converted to the integer <TT CLASS="LITERAL" >0</TT > or the double <TT CLASS="LITERAL" >0.0</TT > is treated as false, as is the empty string or the constant string <TT CLASS="LITERAL" >false</TT >. Anything else is interpreted as true. The result is either <TT CLASS="LITERAL" >0</TT > or <TT CLASS="LITERAL" >1</TT >.</P ><P >The conditional operator <TT CLASS="LITERAL" >? :</TT > will interpret its first operand as a boolean. It does not perform any processing on the second or third operands.</P ><P >In practice it is rarely necessary to worry about any of these details. In nearly every case <SPAN CLASS="APPLICATION" >CDL</SPAN > expressions just work as expected, and there is no need to understand the full details.</P ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B >Note: </B >The current expression syntax does not meet all the needs of component writers. Some future enhancements will definitely be made, others are more controversial. The list includes the following:</P ><P ></P ><OL TYPE="1" ><LI ><P >An option's value is determined by several different factors: whether or not it is loaded, whether or not it is active, whether or not it is enabled, and the data part. Currently there is no way of querying these individually. This is very significant in the context of options with the <TT CLASS="LITERAL" >bool</TT > or <TT CLASS="LITERAL" >booldata</TT > flavors, because there is no way of distinguishing between the option being absent/inactive/disabled or it being enabled with a data field of <TT CLASS="LITERAL" >0</TT >. There should be unary operators that allow any of the factors to be checked.</P ></LI ><LI ><P >Only the <TT CLASS="LITERAL" >==</TT > and <TT CLASS="LITERAL" >!=</TT > operators can be used for string data. More string-related facilities are needed.</P ></LI ><LI ><P >An implies operator would be useful for many goal expression, where <TT CLASS="LITERAL" >A implies B</TT > is equivalent to <TT CLASS="LITERAL" >!A ||B</TT >.</P ></LI ><LI ><P >Similarly there is inadequate support for lists. On occasion it would be useful to write expressions involving say the list of implementors of a given CDL interface, for example a sensible default value could be the first implementor. Associated with this is a need for an indirection operator.</P ></LI ><LI ><P >Arguably extending the basic <SPAN CLASS="APPLICATION" >CDL</SPAN > expression syntax with lots of new operators is unnecessary, instead expressions should just support <SPAN CLASS="APPLICATION" >Tcl</SPAN > command substitution and then component writers could escape into <SPAN CLASS="APPLICATION" >Tcl</SPAN > scripts for complicated operations. This has some major disadvantages. First, the inference engine would no longer have any sensible way of interpreting an expression to resolve a conflict. Second, the component framework's value propagation code keeps track of which options get referenced in which expressions and avoids unnecessary re-evaluation of expressions; if expressions can involve arbitrary <SPAN CLASS="APPLICATION" >Tcl</SPAN > code then there is no simple way to eliminate unnecessary recalculations, with a potentially major impact on performance.</P ></LI ></OL ></BLOCKQUOTE ></DIV ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B >Note: </B >The current implementation of the component framework uses 64 bit arithmetic on all host platforms. Although this is adequate for current target architectures, it may cause problems in future. At some stage it is likely that an arbitrary precision integer arithmetic package will be used instead.</P ></BLOCKQUOTE ></DIV ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LANGUAGE.FUNCTIONS">Functions</H2 ><P >CDL expressions can contain calls to a set of built-in functions using the usual syntax, for example;</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, "-fno-rtti") }</PRE ></TD ></TR ></TABLE ><P >The available function calls are as follows:</P ><P ></P ><DIV CLASS="VARIABLELIST" ><DL ><DT ><TT CLASS="LITERAL" >get_data(option)</TT ></DT ><DD ><P >This function can be used to obtain just the data part of a loaded configuration option, ignoring other factors such as whether or not the option is active and enabled. It takes a single argument which should be the name of a configuration option. If the specified option is not loaded in the current configuration then the function returns 0, otherwise it returns the data part. Typically this function will only be used in conjunction with <TT CLASS="FUNCTION" >is_active</TT > and <TT CLASS="FUNCTION" >is_enabled</TT > for fine-grained control over the various factors that make up an option's value.</P ></DD ><DT ><TT CLASS="LITERAL" >is_active(option)</TT ></DT ><DD ><P >This function can be used to determine whether or not a particular configuration option is active. It takes a single argument which should be the name of an option, and returns a boolean. If the specified option is not loaded then the function will return false. Otherwise it will consider the state of the option's parents and evaluate any <SPAN CLASS="PROPERTY" >active_if</SPAN > properties, and return the option's current active state. A typical use might be:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { is_active(CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE) implies (CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE >= (16 * 1024)) }</PRE ></TD ></TR ></TABLE ><P >In other words either the specified configuration option must be inactive, for example because the current application does not use any related C library or POSIX functionality, or the stack size must be at least 16K.</P ><P >The configuration system's inference engine can attempt to satisfy constraints involving <TT CLASS="FUNCTION" >is_active</TT > in various different ways, for example by enabling or disabling parent components, or by examining <SPAN CLASS="PROPERTY" >active_if</SPAN > properties and manipulating terms in the associated expressions.</P ></DD ><DT ><TT CLASS="LITERAL" >is_enabled(option)</TT ></DT ><DD ><P >This function can be used to determine whether or not a particular configuration option is enabled. It takes a single argument which should be the name of an option, and returns a boolean. If the specified option is not loaded then the function will return false. Otherwise it will return the current boolean part of the option's value. The option's active or inactive state is ignored. Typically this function will be used in conjunction with <TT CLASS="FUNCTION" >is_active</TT > and possibly <TT CLASS="FUNCTION" >get_data</TT > to provide fine-grained control over the various factors that make up an option's value.</P ></DD ><DT ><TT CLASS="LITERAL" >is_loaded(option)</TT ></DT ><DD ><P >This function can be used to determine whether or not a particular configuration option is loaded. It takes a single argument which should be the name of an option, and returns a boolean. If the argument is a package then the <TT CLASS="FUNCTION" >is_loaded</TT > function provides little or no extra information, for example the following two constraints are usually equivalent:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { CYGPKG_KERNEL } requires { is_loaded(CYGPKG_KERNEL) }</PRE ></TD ></TR ></TABLE ><P >However if the specified package is loaded but re-parented below a disabled component, or inactive as a result of an <SPAN CLASS="PROPERTY" >active_if</SPAN > property, then the first constraint would not be satisfied but the second constraint would. In other words the <TT CLASS="FUNCTION" >is_loaded</TT > makes it possible to consider in isolation one of the factors that are considered when CDL expressions are evaluated.</P ><P >The configuration system's inference engine will not automatically load or unload packages to satisfy <TT CLASS="FUNCTION" >is_loaded</TT > constraints. </P ></DD ><DT ><TT CLASS="LITERAL" >is_substr(haystack, needle)</TT ></DT ><DD ><P >This can be used to check whether or not a particular string is present in another string. It is used mainly for manipulating compiler flags. The function takes two arguments, both of which can be arbitrary expressions, and returns a boolean.</P ><P ><TT CLASS="FUNCTION" >is_substr</TT > has some understanding of word boundaries. If the second argument starts with a space character then that will match either a real space or the start of the string. Similarly if the second argument ends with a space character then that will match a real space or the end of the string. For example, all of the following conditions are satisfied:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > is_substr("abracadabra", "abra") is_substr("abracadabra", " abra") is_substr("hocus pocus", " pocus") is_substr("abracadabra", "abra ")</PRE ></TD ></TR ></TABLE ><P >The first is an exact match. The second is a match because the leading space matches the start of the string. The third is an exact match, with the leading space matching an actual space. The fourth is a match because the trailing space matches the end of the string. However, the following condition is not satisfied.</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > is_substr("abracadabra", " abra ")</PRE ></TD ></TR ></TABLE ><P >This fails to match at the start of the string because the trailing space is not matched by either a real space or the end of the string. Similarly it fails to match at the end of the string.</P ><P >If a constraint involving <TT CLASS="FUNCTION" >is_substr</TT > is not satisfied and the first argument is a reference to a configuration option, the inference engine will attempt to modify that option's value. This can be achieved either by appending the second argument to the current value, or by removing all occurrences of that argument from the current value.</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, " -fno-rtti ") } requires { is_substr(CYGBLD_GLOBAL_CFLAGS, " -frtti ") }</PRE ></TD ></TR ></TABLE ><P >When data is removed the leading and trailing spaces will be left. For example, given an initial value of <<TT CLASS="VARNAME" >CYGBLD_GLOBAL_CFLAGS</TT > of <TT CLASS="LITERAL" >-g -fno-rtti -O2</TT > the result will be <TT CLASS="LITERAL" >-g -O2</TT > rather than <TT CLASS="LITERAL" >-g-O2</TT >.</P ><P >If exact matches are needed, the function <TT CLASS="FUNCTION" >is_xsubstr</TT > can be used instead.</P ></DD ><DT ><TT CLASS="LITERAL" >is_xsubstr(haystack, needle)</TT ></DT ><DD ><P >This function checks whether or not the pattern string is an exact substring of the string being searched. It is similar to <TT CLASS="FUNCTION" >is_substr</TT > but uses exact matching only. In other words, leading or trailing spaces have to match exactly and will not match the beginning or end of the string being searched. The function takes two arguments, both of which can be arbitrary expressions, and returns a boolean. The difference between <TT CLASS="FUNCTION" >is_substr</TT > and <TT CLASS="FUNCTION" >is_xsubstr</TT > is illustrated by the following examples:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > cdl_option MAGIC { flavor data default_value { "abracadabra" } } … requires { is_substr(MAGIC, " abra") } requires { is_xsubstr(MAGIC, " abra") }</PRE ></TD ></TR ></TABLE ><P >The first goal will be satisfied because the leading space in the pattern matches the beginning of the string. The second goal will not be satisfied initialy because there is no exact match, so the inference engine is likely to update the value of <TT CLASS="VARNAME" >MAGIC</TT > to <TT CLASS="LITERAL" >abracadabra abra</TT > which does give an exact match.</P ></DD ><DT ><TT CLASS="LITERAL" >version_cmp(A, B)</TT ></DT ><DD ><P >This function is used primarily to check that a sufficiently recent <A HREF="package.versions.html" >version</A > of some other package is being used. It takes two arguments, both of which can be arbitrary expressions. In practice usually one of the arguments will be a reference to a package and the other will be a constant version string. The return value is -1 if the first argument is a more recent version then the second, 0 if the two arguments correspond to identical versions, and 1 if the first argument is an older version. For example the following constraint can be used to indicate that the current package depends on kernel functionality that only became available in version 1.3:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { version_cmp(CYGPKG_KERNEL, "v1.3") <= 0 }</PRE ></TD ></TR ></TABLE ></DD ></DL ></DIV ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B >Note: </B >At this time it is not possible to define new functions inside a CDL script. Instead functions can only be added at the C++ level, usually by extending libcdl itself. This is partly because there is more to CDL functions than simple evaluation: associated with most functions is support for the inference engine, so that if a constraint involving a function is not currently satisfied the system may be able to find a solution automatically.</P ></BLOCKQUOTE ></DIV ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LANGUAGE.GOAL-EXPRESSION">Goal Expressions</H2 ><P >The arguments to certain properties, notably <SPAN CLASS="PROPERTY" >requires</SPAN > and <SPAN CLASS="PROPERTY" >active_if</SPAN >, constitute a goal expression. As with an ordinary expression, all of the arguments get combined and then the expression parser takes over. The same care has to be taken with constant strings and anything else that may get processed by the Tcl interpreter, so often a goal expression is enclosed entirely in braces and the expression parsing code sees just a single argument.</P ><P >A goal expression is basically just a sequence of ordinary expressions, for example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT }</PRE ></TD ></TR ></TABLE ><P >This consists of three separate expressions, all of which should evaluate to a non-zero result. The same expression could be written as: </P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires { CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS && !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT && !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT }</PRE ></TD ></TR ></TABLE ><P >Alternatively the following would have much the same effect:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS requires !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT requires !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT</PRE ></TD ></TR ></TABLE ><P >Selecting between these alternatives is largely a stylistic choice. The first is slightly more concise than the others. The second is more likely to appeal to mathematical purists. The third is more amenable to cutting and pasting.</P ><P >The result of evaluating a goal expression is a boolean. If any part of the goal expression evaluates to the integer <TT CLASS="LITERAL" >0</TT > or an equivalent string then the result is false, otherwise it is true. </P ><P >The term “goal expression” relates to the component framework's inference engine: it is a description of a goal that should be satisfied for a conflict-free configuration. If a <SPAN CLASS="PROPERTY" >requires</SPAN > constraint is not satisfied then the inference engine will examine the goal expression: if there is some way of changing the configuration that does not introduce new conflicts and that will cause the goal expression to evaluate to true, the conflict can be resolved.</P ><P >The inference engine works with one conflict and hence one goal expression at a time. This means that there can be slightly different behavior if a constraint is specified using a single <SPAN CLASS="PROPERTY" >requires</SPAN > property or several different ones. Given the above example, suppose that none of the three conditions are satisfied. If a single goal expression is used then the inference engine might be able to satisfy only two of the three parts, but since the conflict as a whole cannot be resolved no part of the solution will be applied. Instead the user will have to resolve the entire conflict. If three separate goal expressions are used then the inference engine might well find solutions to two of them, leaving less work for the user. On the other hand, if a single goal expression is used then the inference engine has a bit more information to work with, and it might well find a solution to the entire conflict where it would be unable to find separate solutions for the three parts. Things can get very complicated, and in general component writers should not worry about the subtleties of the inference engine and how to manipulate its behavior. </P ><P >It is possible to write ambiguous goal expressions, for example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires CYGNUM_LIBC_RAND_SEED -CYGNUM_LIBC_RAND_TRACE_LEVEL > 5</PRE ></TD ></TR ></TABLE ><P >This could be parsed in two ways:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > requires ((CYGNUM_LIBC_RAND_SEED - CYGNUM_LIBC_RAND_TRACE_LEVEL) > 5) requires CYGNUM_LIBC_RAND_SEED && ((-CYGNUM_LIBC_RAND_TRACE_LEVEL) > 5)</PRE ></TD ></TR ></TABLE ><P >The goal expression parsing code will always use the largest ordinary expression for each goal, so the first interpretation will be used. In such cases it is a good idea to use brackets and avoid possible confusion. </P ></DIV ><DIV CLASS="SECT2" ><H2 CLASS="SECT2" ><A NAME="LANGUAGE.LIST-EXPRESSION">List Expressions</H2 ><P >The arguments to the <SPAN CLASS="PROPERTY" >legal_values</SPAN > property constitute a goal expression. As with an ordinary and goal expressions, all of the arguments get combined and then the expression parser takes over. The same care has to be taken with constant strings and anything else that may get processed by the Tcl interpreter, so often a list expression is enclosed entirely in braces and the expression parsing code sees just a single argument.</P ><P >Most list expressions take one of two forms:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > legal_values <expr1> <expr2> <expr3> ... legal_values <expr1> to <expr2></PRE ></TD ></TR ></TABLE ><P ><TT CLASS="LITERAL" >expr1</TT >, <TT CLASS="LITERAL" >expr2</TT > and so on are ordinary expressions. Often these will be constants or references to calculated options in the architectural HAL package, but it is possible to use arbitrary expressions when necessary. The first syntax indicates a list of possible values, which need not be numerical. The second syntax indicates a numerical range: both sides of the <TT CLASS="LITERAL" >to</TT > must evaluate to a numerical value; if either side involves a floating point number then any floating point number in that range is legal; otherwise only integer values are legal; ranges are inclusive, so <TT CLASS="LITERAL" >4</TT > is a valid value given a list expression <TT CLASS="LITERAL" >1 to </TT >; if one or both sides of the <TT CLASS="LITERAL" >to</TT > does not evaluate to a numerical value then this will result in a run-time conflict. The following examples illustrate these possibilities:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > legal_values { "red" "green" "blue" } legal_values 1 2 4 8 16 legal_values 1 to CYGARC_MAXINT legal_values 1.0 to 2.0</PRE ></TD ></TR ></TABLE ><P >It is possible to combine the two syntaxes, for example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > legal_values 1 2 4 to CYGARC_MAXINT -1024 -20.0 to -10</PRE ></TD ></TR ></TABLE ><P >This indicates three legal values <TT CLASS="LITERAL" >1</TT >, <TT CLASS="LITERAL" >2</TT > and <TT CLASS="LITERAL" >-1024</TT >, one integer range <TT CLASS="LITERAL" >4 to CYGARC_MAXINT</TT >, and one floating point range <TT CLASS="LITERAL" >-20.0 to -10.0</TT >. In practice such list expressions are rarely useful.</P ><P >The identifier <TT CLASS="VARNAME" >to</TT > is not reserved, so it is possible to have a configuration option with that name (although it violates every naming convention). Using that option in a list expression may however give unexpected results.</P ><P >The graphical configuration tool uses the <SPAN CLASS="PROPERTY" >legal_values</SPAN > list expression to determine how best to let users manipulate the option's value. Different widgets will be appropriate for different lists, so <TT CLASS="LITERAL" >{ "red" "green" "blue" }</TT > might involve a pull-down option menu, and <TT CLASS="LITERAL" >1 to 16</TT > could involve a spinner. The exact way in which <SPAN CLASS="PROPERTY" >legal_values</SPAN > lists get mapped on to GUI widgets is not defined and is subject to change at any time.</P ><P >As with goal expressions, list expressions can be ambiguous. Consider the following hypothetical example:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > legal_values CYGNUM_LIBC_RAND_SEED -CYGNUM_LIBC_RAND_TRACE_LEVEL</PRE ></TD ></TR ></TABLE ><P >This could be parsed in two ways:</P ><TABLE BORDER="5" BGCOLOR="#E0E0F0" WIDTH="70%" ><TR ><TD ><PRE CLASS="PROGRAMLISTING" > legal_values (CYGNUM_LIBC_RAND_SEED - CYGNUM_LIBC_RAND_TRACE_LEVEL) legal_values (CYGNUM_LIBC_RAND_SEED) (-CYGNUM_LIBC_RAND_TRACE_LEVEL)</PRE ></TD ></TR ></TABLE ><P >Both are legal. The list expression parsing code will always use the largest ordinary expression for each element, so the first interpretation will be used. In cases like this it is a good idea to use brackets and avoid possible confusion.</P ></DIV ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="language.tcl.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="cdl-guide.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="language.interface.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >An Introduction to Tcl</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="language.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Interfaces</TD ></TR ></TABLE ></DIV ></BODY ></HTML >
Go to most recent revision | Compare with Previous | Blame | View Log