📄 overview.degress.html
字号:
<!-- 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>Degrees of Configurability</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="The eCos Component Writer's Guide"HREF="cdl-guide.html"><LINKREL="UP"TITLE="Overview"HREF="overview.html"><LINKREL="PREVIOUS"TITLE="Approaches to Configurability"HREF="overview.approaches.html"><LINKREL="NEXT"TITLE="Warnings"HREF="overview.warning.html"></HEAD><BODYCLASS="SECT1"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">The <SPANCLASS="APPLICATION">eCos</SPAN> Component Writer's Guide</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="overview.approaches.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 1. Overview</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="overview.warning.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="OVERVIEW.DEGRESS">Degrees of Configurability</H1><P>Components can support configurability in varying degrees. It is notnecessary to have any configuration options at all, and the only userchoice is whether or not to load a particular package. Alternativelyit is possible to implement highly-configurable code. As an exampleconsider a typical facility that is provided by many real-timekernels, mutex locks. The possible configuration options include:</P><P></P><OLTYPE="1"><LI><P>If no part of the application and no other component requires mutexesthen there is no point in having the mutex code compiled into alibrary at all. This saves having to compile the code. In additionthere will never be any need for the user to configure the detailedbehavior of mutexes. Therefore the presence of mutexes is aconfiguration option in itself.</P></LI><LI><P>Even if the application does make use of mutexes directly orindirectly, this does not mean that all mutex functions have to beincluded. The minimum functionality consists of lock and unlockfunctions. However there are variants of the locking primitive such astry-lock and try-with-timeout which may or may not be needed.</P><P>Generally it will be harmless to compile the try-lock function even ifit is not actually required, because the function will get eliminatedat link-time. Some users might take the view that the try-lockfunction should never get compiled in unless it is actually needed, toreduce compile-time and disk usage. Other users might argue that thereare very few valid uses for a try-lock function and it should not becompiled by default to discourage incorrect uses. The presence of atry-lock function is a possible configuration option, although it maybe sensible to default it to true.</P><P>The try-with-timeout variant is more complicated because it adds adependency: the mutex code will now rely on some other component toprovide a timer facility. To make things worse the presence of thistimer might impact other components, for example it may now benecessary to guard against timer interrupts, and thus have aninsidious effect on code size. The presence of a lock-with-timeoutfunction is clearly a sensible configuration option, but the defaultvalue is less obvious. If the option is enabled by default then thefinal application image may end up with code that is not actuallyessential. If the option is disabled by default then users will haveto enable the option somehow in order to use the function, implyingmore effort on the part of the user. One possible approach is tocalculate the default value based on whether or not a timer componentis present anyway.</P></LI><LI><P>The application may or may not require the ability to create anddestroy mutexes dynamically. For most embedded systems it is both lesserror-prone and more efficient to create objects like mutexesstatically. Dynamic creation of mutexes can be implemented using apre-allocated pool of mutex objects, involving some extra code tomanipulate the pool and an additional configuration option to definethe size of the pool. Alternatively it can be implemented using ageneral-purpose memory allocator, involving quite a lot of extra codeand configuration options. However this general-purpose memoryallocator may be present anyway to support the application itself orsome other component. The ability to create and destroy mutexesdynamically is a configuration option, and there may not be a sensibledefault that is appropriate for all applications.</P></LI><LI><P>An important issue for mutex locks is the handling of priorityinversion, where a high priority thread is prevented from runningbecause it needs a lock owned by a lower priority thread. This is onlyan issue if there is a scheduler with multiple priorities: somesystems may need multi-threading and hence synchronization primitives,but a single priority level may suffice. If priority inversion is atheoretical possibility then the application developer may still wantto ignore it because the application has been designed such that theproblem cannot arise in practice. Alternatively the developer may wantsome sort of exception raised if priority inversion does occur,because it should not happen but there may still be bugs in the code.If priority inversion can occur legally then there are three main waysof handling it: priority ceilings, priority inheritance, and ignoringthe problem. Priority ceilings require little code but extra effort onthe part of the application developer. Priority inheritance requiresmore code but is automatic. Ignoring priority inversion may or may notbe acceptable, depending on the application and exactly when priorityinversion can occur. Some of these choices involve additionalconfiguration options, for example there are different ways of raisingan exception, and priority inheritance may or may not be appliedrecursively.</P></LI><LI><P>As a further complication some mutexes may be hidden inside acomponent rather than being an explicit part of the application. Forexample, if the C library is configured to provide a<TTCLASS="FUNCTION">malloc</TT> call then there may be an associated mutexto make the function automatically thread-safe, with no need forexternal locking. In such cases the memory allocation component of theC library can impose a constraint on the kernel, requiring thatmutexes be provided. If the user attempts to disable mutexes anywaythen the configuration tools will report a conflict.</P></LI><LI><P>The mutex code should contain some general debugging code such asassertions and tracing. Usually such debug support will be enabled ordisabled at a coarse level such as the entire system or everythinginside the kernel, but sometimes it will be desirable to enable thesupport more selectively. One reason would be memory requirements: thetarget may not have enough memory to hold the system if all debuggingis enabled. Another reason is if most of the system is working butthere are a few problems still to resolved; enabling debugging in theentire system might change the system's timing behavior too much, butenabling some debug options selectively can still be useful. Thereshould be configuration options to allow specific types of debuggingto be enabled at a fine-grain, but with default settings inheritedfrom an enclosing component or from global settings.</P></LI><LI><P>The mutex code may contain specialized code to interactwith a debugging tool running on the host. It should bepossible to enable or disable this debugging code, and there maybe additional configuration options controlling the detailedbehavior.</P></LI></OL><P>Altogether there may be something like ten to twenty configurationoptions that are specific to the mutex code. There may be a similarnumber of additional options related to assertions and other debugfacilities. All of the options should have sensible default values,possibly fixed, possibly calculated depending on what is happeningelsewhere in the configuration. For example the default setting foran assertion option should generally inherit from a kernel-wideassertion control option, which in turn inherits from a global option.This allows users to enable or disable assertions globally or ata more fine-grained level, as desired.</P><P>Different components may be configurable to different degrees, rangingfrom no options at all to the fine-grained configurability of theabove mutex example (or possibly even further). It is up to componentwriters to decide what options should be provided and how best toserve the needs of application developers who want to use thatcomponent.</P></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="overview.approaches.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="cdl-guide.html"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="overview.warning.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Approaches to Configurability</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="overview.html"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Warnings</TD></TR></TABLE></DIV></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -