#ifndef CYGONCE_PKGCONF_KERNEL_H#define CYGONCE_PKGCONF_KERNEL_H// ====================================================================////      pkgconf/kernel.h////      Kernel configuration file//// ====================================================================//####COPYRIGHTBEGIN####//// -------------------------------------------// The contents of this file are subject to the Cygnus eCos Public License// Version 1.0 (the "License"); you may not use this file except in// compliance with the License.  You may obtain a copy of the License at// http://sourceware.cygnus.com/ecos// // Software distributed under the License is distributed on an "AS IS"// basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.  See the// License for the specific language governing rights and limitations under// the License.// // The Original Code is eCos - Embedded Cygnus Operating System, released// September 30, 1998.// // The Initial Developer of the Original Code is Cygnus.  Portions created// by Cygnus are Copyright (C) 1998,1999 Cygnus Solutions.  All Rights Reserved.// -------------------------------------------////####COPYRIGHTEND####// ====================================================================//#####DESCRIPTIONBEGIN####//// Author(s):   nickg// Contributors:        nickg// Date:        1997-09-29      // Purpose:     To allow the user to edit kernel configuration options.// Description:////####DESCRIPTIONEND####//// ====================================================================/* --------------------------------------------------------------------- * Some of the kernel configuration options depend on global options, * so it is necessary to include the global options first. */#include <pkgconf/system.h>/* Only define options if the kernel is to be present */#ifdef CYGPKG_KERNEL#include <pkgconf/hal.h>#include <pkgconf/infra.h>/* --------------------------------------------------------------------- * The overall package definition. {{CFG_DATA  cdl_package CYGPKG_KERNEL {     display  "eCos kernel"     type     boolean     requires CYGFUN_HAL_COMMON_KERNEL_SUPPORT     description "         This package contains the core functionality of the eCos         kernel. It relies on functionality provided by various HAL         packages and by the eCos infrastructure. In turn the eCos         kernel provides support for other packages such as the device         drivers and the uITRON compatibility layer."     doc ref/ecos-ref/ecos-kernel-overview.html } }}CFG_DATA *//* --------------------------------------------------------------------- * The first component within the kernel is related to interrupt * handling. {{CFG_DATA cdl_component CYGPKG_KERNEL_INTERRUPTS {     display "Kernel interrupt handling"     parent  CYGPKG_KERNEL     type    dummy     description "         The majority of configuration options related to interrupt         handling are in the HAL packages, since usually the code has         to be platform-specific. There are a number of options         provided within the kernel related to slightly higher-level         concepts, for example Delayed Service Routines."     doc ref/ecos-ref/interrupts.html } # In the absence of active-if support this has to be # a sub-component. It does not use the CYGPKG_ prefix to make # it easier to change back into an ordinary option later on. cdl_component CYGIMP_KERNEL_INTERRUPTS_DSRS {     display     "Use delayed service routines (DSRs)"     parent      CYGPKG_KERNEL_INTERRUPTS     description "         In eCos the recommended way to handle device interrupts is to         do a minimum amount of work inside the low level interrupt         handler itself, and instead do as much as possible in a         Delayed Service Routine or DSR. If an application does not         make use of DSRs directly or indirectly then it is possible         to disable the DSR support completely, which reduces the         overheads of context switches and interrupt handling. Note         that the kernel real-time clock makes use of DSRs, as do many         of the device drivers. "     doc ref/ecos-ref/interrupt-and-exception-handlers.html     } # NOTE: the choice of list vs table should not be two separate # options. There is a single option which must have one of # two legal values. cdl_option CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST {     display "Use linked lists for DSRs"     parent  CYGIMP_KERNEL_INTERRUPTS_DSRS     type    radio     description "         When DSR support is enabled the kernel must keep track of all         the DSRs that are pending. This information can be kept in a         fixed-size table or in a linked list. The list implementation         requires that the kernel disable interrupts for a very short         period of time outside interrupt handlers, but there is no         possibility of a table overflow occurring."     doc ref/ecos-ref/interrupts.html } cdl_option CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE {     display "Use fixed-size table for DSRs"     parent  CYGIMP_KERNEL_INTERRUPTS_DSRS     type    radio     description "         When DSR support is enabled the kernel must keep track of all         the DSRs that are pending. This information can be kept in a         fixed-size table or in a linked list. The table         implementation involves a very small risk of overflow at         run-time if a given interrupt source is able to have more         than one pending DSR. However it has the advantage that         the kernel does not need to disable interrupts outside         interrupt handlers."     doc ref/ecos-ref/interrupts.html } cdl_option CYGNUM_KERNEL_INTERRUPTS_DSRS_TABLE_SIZE {     display            "Number of entries in fixed-size DSR table"     parent             CYGIMP_KERNEL_INTERRUPTS_DSRS     type               count     legal_values       2 to 1024     #active_if CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE     description "         When DSR support is enabled the kernel must keep track of all         the DSRs that are pending. One approach involves a fixed-size         table, which involves a very small risk of overflow at         run-time. By increasing the table size it is possible to reduce         this risk."     doc ref/ecos-ref/interrupts.html     } cdl_option CYGIMP_KERNEL_INTERRUPTS_CHAIN {     display            "Chain all interrupts together"     parent             CYGPKG_KERNEL_INTERRUPTS     requires           CYGIMP_HAL_COMMON_INTERRUPTS_CHAIN     description "         Interrupts can be attached to vectors either singly, or be         chained together. The latter is necessary if there is no way         of discovering which device has interrupted without         inspecting the device itself. It can also reduce the amount         of RAM needed for interrupt decoding tables and code."     doc ref/ecos-ref/interrupts.html } }}CFG_DATA */#define CYGIMP_KERNEL_INTERRUPTS_DSRS#define CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST#undef  CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE#define CYGNUM_KERNEL_INTERRUPTS_DSRS_TABLE_SIZE 32#undef  CYGIMP_KERNEL_INTERRUPTS_CHAIN/* --------------------------------------------------------------------- * Exceptions. Currently there are only two options. The first * determines whether or not exceptions are enabled at all. The * second controls whether they apply globally or on a per-thread * basis. There should probably be more options, but the boundary * between the HAL and kernel becomes blurred.    {{CFG_DATA   cdl_component CYGPKG_KERNEL_EXCEPTIONS {       display "Exception handling"       parent  CYGPKG_KERNEL       requires CYGPKG_HAL_EXCEPTIONS       description "           In the context of the eCos kernel exceptions are unexpected           events detected by the hardware, for example an attempt to           execute an illegal instruction. There is no relation with           other forms of exception, for example the catch and throw           facilities of languages like C++. It is possible to disable           all support for exceptions and thus save some memory."       doc ref/ecos-ref/exceptions.html   }   cdl_option CYGSEM_KERNEL_EXCEPTIONS_DECODE {       display "Decode exception types in kernel"       parent  CYGPKG_KERNEL_EXCEPTIONS       description "           On targets where several different types of exception are           possible, for example executing an illegal instruction and           division by zero, it is possible for the kernel to do some           decoding of the exception type and deliver the different           types of exception to different handlers in the application           code. Alternatively the kernel can simply pass all           exceptions directly to application code, leaving the           decoding to be done by the application"       doc ref/ecos-ref/exceptions.html   }      cdl_option CYGSEM_KERNEL_EXCEPTIONS_GLOBAL {       display "Use global exception handlers"       parent  CYGPKG_KERNEL_EXCEPTIONS       description "           In the context of the eCos kernel exceptions are unexpected           events detected by the hardware, for example an attempt to           execute an illegal instruction. If the kernel is configured           to support exceptions then two implementations are           possible. The default implementation involves a single set           of exception handlers that are in use for the entire           system. The alternative implementation allows different           exception handlers to be specified for each thread."       doc ref/ecos-ref/exceptions.html   }      }}CFG_DATA */#define CYGPKG_KERNEL_EXCEPTIONS#undef  CYGSEM_KERNEL_EXCEPTIONS_DECODE#define CYGSEM_KERNEL_EXCEPTIONS_GLOBAL/* --------------------------------------------------------------------- * {{CFG_DATA cdl_component CYGPKG_KERNEL_SCHED {     display "Kernel schedulers"     type    dummy     parent  CYGPKG_KERNEL     description "         The eCos kernel provides a choice of schedulers. In addition         there are a number of configuration options to control the         detailed behaviour of these schedulers.     "     doc ref/ecos-ref/ecos-kernel-overview.html#THE-SCHEDULER } cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE {     display    "Multi-level queue scheduler"     type       radio     parent     CYGPKG_KERNEL_SCHED     description "         The multi-level queue scheduler supports multiple priority         levels and multiple threads at each priority level.         Preemption between priority levels is automatic. Timeslicing         within a given priority level is controlled by a separate         configuration option"     doc ref/ecos-ref/ecos-kernel-overview.html#THE-SCHEDULER }  cdl_option CYGSEM_KERNEL_SCHED_BITMAP {     display    "Bitmap scheduler"     type       radio     parent     CYGPKG_KERNEL_SCHED     description "         The bitmap scheduler supports multiple priority levels but         only one thread can exist at each priority level. This means         that scheduling decisions are very simple and hence the         scheduler is efficient. Preemption between priority levels is         automatic. Timeslicing within a given priority level is         irrelevant since there can be only one thread at each         priority level."     doc ref/ecos-ref/ecos-kernel-overview.html#THE-SCHEDULER } #cdl_option CYGSEM_KERNEL_SCHED_LOTTERY { #    display    "Lottery scheduler" #    type       radio #    parent     CYGPKG_KERNEL_SCHED #    description " #       This scheduler is not yet available." #} # NOTE: this option only makes sense if the current scheduler # supports multiple priority levels. cdl_option CYGNUM_KERNEL_SCHED_PRIORITIES {     display            "Number of priority levels"     type               count     legal_values       1 to 32     parent             CYGPKG_KERNEL_SCHED     #active_if         CYGINT_KERNEL_SCHED_PRIORITY_SCHEDULER     description "         This option controls the number of priority levels that are         available. For some types of scheduler including the bitmap         scheduler this may impose an upper bound on the number of         threads in the system. For other schedulers such as the         mlqueue scheduler the number of threads is independent from         the number of priority levels. Note that the lowest priority         level is normally used only by the idle thread, although         application threads can run at this priority if necessary."     doc ref/ecos-ref/ecos-kernel-overview.html#THE-SCHEDULER }  # NOTE: this option only makes sense for some of the schedulers.  # Timeslicing is irrelevant for bitmap schedulers.  cdl_option CYGSEM_KERNEL_SCHED_TIMESLICE {      display           "Scheduler timeslicing"      parent            CYGPKG_KERNEL_SCHED      requires          !CYGSEM_KERNEL_SCHED_BITMAP      requires          CYGVAR_KERNEL_COUNTERS_CLOCK      description "