⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 overview.approaches.html

📁 有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等
💻 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>Approaches to 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="Why Configurability?"HREF="overview.configurability.html"><LINKREL="NEXT"TITLE="Degrees of Configurability"HREF="overview.degress.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.configurability.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 1. Overview</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="overview.degress.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="OVERVIEW.APPROACHES">Approaches to Configurability</H1><P>The purpose of configurability is to control the behavior ofcomponents. A scheduler component may or may not support time slicing;it may or may not support multiple priorities; it may or may notperform error checking on arguments passed to the scheduler routines.In the context of a desktop application a button widget may containsome text or it may contain a picture; the text may be displayed in avariety of fonts; the foreground and background color may vary. Whenan application uses a component there must be some way of specifyingthe desired behavior. The component writer has no way of knowing inadvance exactly how a particular component will end up being used.</P><P>One way to control the behavior is at run time. The applicationcreates an instance of a button object, and then instructs this objectto display either text or a picture. No special effort by theapplication developer is required, since a button can always supportall desired behavior. There is of course a major disadvantage interms of the size of the final application image: the code that getslinked with the application has to provide support for all possiblebehavior, even if the application does not require it.</P><P>Another approach is to control the behavior at link-time, typicallyby using inheritance in an object-oriented language. The buttonlibrary provides an abstract base class <TTCLASS="CLASSNAME">Button</TT>and derived classes <TTCLASS="CLASSNAME">TextButton</TT> and<TTCLASS="CLASSNAME">PictureButton</TT>. If an application only uses textbuttons then it will only create objects of type<TTCLASS="CLASSNAME">TextButton</TT>, and the code for the<TTCLASS="CLASSNAME">PictureButton</TT> class does not get used. Inmany cases this approach works rather well and reduces the final imagesize, but there are limitations. The main one is that you can onlyhave so many derived classes before the system gets unmanageable: aderived class<TTCLASS="CLASSNAME">TextButtonUsingABorderWidthOfOnePlusAWhiteBackgroundAndBlackForegroundAndATwelvePointTimesFontAndNoErrorCheckingOrAssertions</TT>is not particularly sensible as far as most application developers areconcerned.</P><P>The <SPANCLASS="APPLICATION">eCos</SPAN> component framework allows the behavior of components tobe controlled at an even earlier time: when the component source codegets compiled and turned into a library. The button component couldprovide options, for example an option that only text buttons need tobe supported. The component gets built and becomes part of a libraryintended specifically for the application, and the library willcontain only the code that is required by this application and nothingelse. A different application with different requirements would needits own version of the library, configured separately.</P><P>In theory compile-time configurability should give the best possibleresults in terms of code size, because it allows code to be controlledat the individual statement level rather than at the function orobject level. Consider an example more closely related to embeddedsystems, a package to support multi-threading. A standard routinewithin such a package allows applications to kill threadsasynchronously: the POSIX routine for this is<TTCLASS="FUNCTION">pthread_cancel</TT>; the equivalent routine in &micro;ITRONis <TTCLASS="FUNCTION">ter_tsk</TT>. These routines themselves tend toinvolve a significant amount of code, but that is not the realproblem: other parts of the system require extra code and data for thekill routine to be able to function correctly. For example if a threadis blocked while waiting on a mutex and is killed off by anotherthread then the kill operation may have to do two things: remove thethread from the mutex's queue of waiting threads; and undo theeffects, if any, of priority inheritance. The implementation requiresextra fields in the thread data structure so that the kill routineknows about the thread's current state, and extra code in the mutexroutines to fill in and clear these extra fields correctly.</P><P>Most embedded applications do not require the ability to kill off athread asynchronously, and hence the kill routine will not get linkedinto the final application image. Without compile-time configurabilitythis would still mean that the mutex code and similar parts of thesystem contain code and data that serve no useful purpose in thisapplication. The <SPANCLASS="APPLICATION">eCos</SPAN> approach allows the user to select that thethread kill functionality is not required, and all the components canadapt to this at compile-time. For example the code in the mutex lockroutine contains statements to support the killing of threads, butthese statements will only get compiled in if that functionality isrequired. The overall result is that the final application imagecontains only the code and data that is really needed for theapplication to work, and nothing else.</P><P>Of course there are complications. To return to the button example,the application code might only use text buttons directly, but itmight also use some higher-level widget such as a file selector andthis file selector might require buttons with pictures. Therefore thebutton code must still be compiled to support pictures as well astext. The configuration tools must be aware of the dependenciesbetween components and ensure that the internal constraints are met,as well as the external requirements of the application code. An areaof particular concern is conflicting requirements: a button componentmight be written in such a way that it can only support either textbuttons or picture buttons, but not both in one application; thiswould represent a weakness in the component itself rather than in thecomponent framework as a whole.</P><P>Compile-time configurability is not intended to replace the otherapproaches but rather to complement them. There will be times whenrun-time selection of behavior is desirable: for example anapplication may need to be able to change the baud rate of a serialline, and the system must then provide a way of doing this atrun-time. There will also be times when link-time selection isdesirable: for example a C library might provide two different randomnumber routines <TTCLASS="FUNCTION">rand</TT> and<TTCLASS="FUNCTION">lrand48</TT>; these do not affect other code so thereis no good reason for the C library component not to provide both ofthese, and allow the application code to use none, one, or both ofthem as appropriate; any unused functions will just get eliminated atlink-time. Compile-time selection of behavior is another option, andit can be the most powerful one of the three and the best suited toembedded systems development.</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.configurability.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.degress.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Why Configurability?</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="overview.html"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Degrees of Configurability</TD></TR></TABLE></DIV></BODY></HTML>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -