kconfig

rtai-3.1-test3的源代码(Real-Time Application Interface )

config RTAI_SEM
	tristate "Semaphores"
	default m
	help

	A semaphore is a protocol mechanism offered to:
	  - control access to a shared resource (mutual exclusion);
	  - signal the occurrence of an event;
	  - allow two tasks to synchronize their activities.

	Resource semaphores can be recursively nested and support full
	priority inheritance, both among semaphore resources and
	intertask messages, for a singly owned resource.

	Priority inheritance becomes an adaptive priority ceiling when
	a task owns multiple resources, including messages sent to it.
	Both binary and counting semaphores are able to queue tasks
	either in FIFO or priority order and this can be chosen
	dynamically at run time.

	The module will be called rtai_sem.o.

config RTAI_MSG
	tristate "Message"
	default m
	help
	The module will be called rtai_msg.o.

config RTAI_MBX
	tristate "Mailboxes"
	depends on RTAI_SEM
	default y if RTAI_SEM=y
	default m if RTAI_SEM=m
	help

	A mailbox corresponds to a pointer-size variable which is
	associated to a service provided by the kernel. It allows a
	task or an ISR to deposit a message (the pointer) into this
	mailbox.

	The RTAI mailbox implementation is very flexible as it allows
	to send any message size by using any mailbox buffer
	size. They are based on the First In First Out (FIFO)
	principle and on Last In First Out (LIFO) for urgent delivery.

	Mailboxes depend on semaphores.

	The module will be called rtai_mbx.o.


config RTAI_TBX
	tristate "Typed mailboxes"
	depends on RTAI_SEM
	default y if RTAI_SEM=y
	default m if RTAI_SEM=m
	help

	Typed mailboxes (TBX) are an alternative to the default RTAI
	mailboxes. They offer:

	1- message broadcasting allowing to send a message to all the
	   tasks that are pending on the same TBX;

	2- urgent sending of messages: these messages are not
	   enqueued, but inserted in the head of the queue, bypassing all
	   the other messages already present in TBX;

	3- a priority or fifo wakeup policy that may be set at runtime
	when creating the typed mailbox.

	Typed mailboxes depend on semaphores.

	The module will be called rtai_tbx.o.


config RTAI_MQ
	tristate "POSIX-like message queues"
	depends on RTAI_SEM
	default y if RTAI_SEM=y
	default m if RTAI_SEM=m

	help
	RTAI pqueues implements the message queues section
	of the Posix 1003.1d API. They provide kernel-safe message
	queues.	Message queues depend on semaphores.

	The module will be called rtai_mq.o.

endmenu

menu "Other features"

config RTAI_MATH
	bool "Math support"
	default y

config RTAI_MATH_C99
	bool "C99 standard support"
	depends on RTAI_MATH
	default n

config RTAI_MALLOC
	tristate "Real-time malloc support"
	default y
	help
	RTAI provides a real-time implementation of malloc().
	This allows real-time tasks to allocate and to
	free memory safely whilst executing in the real-time domain.
	The module will be called rtai_malloc.o.

config RTAI_MALLOC_VMALLOC
	bool "Use vmalloc() support"
	depends on RTAI_EXTENDED && RTAI_MALLOC
	default n
	help
	RTAI's malloc support offers two different ways to allocate
	memory chunks.

	The reasons for using vmalloc:
	- it is simpler to share allocated buffers with user space;
	- it doesn't have the size restriction of kmalloc.

	The reasons for using kmalloc:
	- it is faster;
	- it exhibits contiguous buffer addressing needed for DMA
	  controllers which don't have scattering/gathering capability.

	The default is using kmalloc()

config RTAI_TASKLETS
	tristate "Tasklets"
	default m
	help

	The tasklets module adds an interesting new feature along the
	line, pioneered by RTAI, of a symmetric usage of all its
	services inter-intra kernel and user space for both soft and
	hard real-time. The new services provided can be useful when
	you have many tasks, both in kernel and user space, that must
	execute in hard real-time but do not need any RTAI scheduler
	services that could lead to a task block.

	Such tasks are called tasklets and can be of two kinds:
        - a simple tasklet;
        - timed tasklets (timers).

	The tasklets implementation of timed tasklets relies on a
	server support task that executes the related timer functions,
	either in oneshot or periodic mode, on the base of their time
	deadline and according to their user assigned priority.

	As explained above, plain tasklets are just functions executed
	from kernel space. Their execution needs no server and is
	simply triggered by calling the user specified tasklet
	function at due time, either from a kernel task or interrupt
	handler in charge of their execution when they are needed.

	The module will be called rtai_tasklets.o.

config RTAI_TRACE
	bool "LTT support"
	default n
	help

	Originally, the Linux Trace Toolkit is a suite of tools
	designed to extract program execution details from the Linux
	operating system and interpret them. Specifically, it enables
	to extract processor utilization and allocation information
	for a certain period of time. It is then possible to perform
	various calculations on this data and dump this in a text
	file. This tool is enhanced by a GTK GUI which allows an easy
	exploitation of those results.  The Linux Trace Toolkit has
	been natively integrated into RTAI modules.
	You may refer to http://www.opersys.com/LTT/ for more information.

config RTAI_USI
	tristate "User-space interrupts"
	default m
	help

	RTAI already contains some examples hinting at managing
	interrupts in user space, e.g: resumefromintr in lxrt-net_rpc,
	pressa in lxrt, but all of them require installing a proper
	handler in kernel space to wake up a hard real-time
	LXRT/NEWLXRT task.

	The user space interrupt support does the same but adds
	something that permits you to avoid writing anything in kernel
	space.

	The module will be called rtai_usi.o.
	

config RTAI_WD
	bool "Watchdog support"
	default y
	help

	The purpose of the watchdog is to provide protection services
	to RTAI thereby protecting it (and the host Linux OS) against
	programming errors in RTAI applications.

	The RTAI module and a scheduler should be mounted to use the
	watchdog and once mounted, it will constantly monitor periodic
	real-time tasks that already exist, or that are created later.
	However this feature is optional and it is assumed that your
	RTAI applications are well behaved so that RTAI should behave
	the same whether or not you have the watchdog mounted. The
	overhead imposed by the watchdog depends on the speed that you
	run it, but in most cases should be minimal.

	The following watchdog policies are possible:
	- do nothing other than log some messages and keep a record of
	  the bad task; 
	- resynchronise the task's frame time and nothing more;
	- debug policy which is a special case of the above
	  resynchronisation policy; 
	- stretch the period of the offending task until it no longer
	  overruns; 
	- slip the offending task by forcibly suspending it for a
	  percentage of its period; 
	- suspend the offending task so that it no longer threaten the system;
	- kill the offending task and remove all traces.

	The module will be called rtai_wd.o.

config RTAI_LEDS
	tristate "LEDS-based debugging support"
	default m
	help

	The module will be called rtai_leds.o.

endmenu

endmenu

menu "Xenomai sub-system"

config RTAI_XENOMAI
	bool "Xenomai sub-system"
	default y
	help

	The Xenomai technology aims at helping application designers
	relying on traditional RTOS to move as smoothly as possible to
	the RTAI execution environment, without having to rewrite
	their application entirely.

	This sub-system contains several emulators mimicking some
	well-known real-time operating systems' API on top of its
	nanokernel.

config RTAI_XENOMAI_DEBUG
	bool "Xenomai debug support"
	depends on RTAI_XENOMAI && RTAI_EXTENDED
	default n
	help
	
	This option activates runtime checking of the Xenomai
	nanokernel state.

config RTAI_XENOMAI_VMLIB
	bool "User-space VM support"
	depends on RTAI_XENOMAI
	default y
	help
	
	RTAI/vm technology allows applications based on legacy RTOS
	APIs to run inside virtual machines in user-space
	with hard real-time capabilities.

	If activated, this option will cause in-kernel emulators
	which have been selected in the "API skins" menu to be
	compiled as process-embeddable virtual machines too.

endmenu

endmenu

menu "Add-ons"

config RTAI_COMEDI_LXRT
	bool "Comedi support over LXRT"
	depends on RTAI_SCHED_LXRT
	default n
	help

	RTAI offers the kcomedilib interface to LXRT real-time
	applications. A kernel module will be built and a library will
	be provided. The kernel modules is called rtai_comedi.o and
	must be loaded if you want to use the libkcomedilxrt.a
	library.

config RTAI_COMEDI_DIR
	depends on RTAI_COMEDI_LXRT
	string "COMEDI installation directory"
	default "/usr/local/comedi"
	help

	You need the COMEDI support for data acquisition to build
	applications such as RTAILab.
	You can set the path to this package's installation
	directory here. More specifically, RTAI needs the file
	linux/comedilib.h.

config RTAI_CPLUSPLUS
	bool "In-kernel C++ support"
	default y
	help

	RTAI offers a C++ framework if you want to develop C++
	real-time applications.

	The module will be called rtai_cpp.o.

config RTAI_SERIAL
	bool "Serial line driver"
	default y
	help

	RTAI provides a real-time serial driver.

	The module will be called rtai_serial.o.

menu "Xenomai skins"

depends on RTAI_XENOMAI

config RTAI_XENOMAI_SKIN_PSOS
	bool "pSOS+ emulator"
	default y if RTAI_XENOMAI_VMLIB=y
	help

	This API skin emulates WindRiver's pSOS+ operating system.

config RTAI_XENOMAI_SKIN_VXWORKS
	bool "VxWorks emulator"
	default y
	help

	This API skin emulates WindRiver's VxWorks operating system.

config RTAI_XENOMAI_SKIN_VRTX
	bool "VRTX emulator"
	default y
	help

	This API skin emulates Mentor Graphics's VRTX operating
	system.

config RTAI_XENOMAI_SKIN_UITRON
	bool "uITRON API"
	default y
	help

	This API skin emulates the uITRON API. 

config RTAI_XENOMAI_SKIN_PSE51
	bool "PSE51 API"
	default y
	help

	This API skin emulates the PSE51 API. 

endmenu

endmenu

menu "RTAI Lab"

config RTAI_LAB
	bool "RTAI Lab"
	default n
	help

	RTAI-Lab is a tool that allows the execution of any suite of
	real-time controllers/simulators automatically generated by
	Matlab/Simulink/RTW, hereafter addressed as RTW, and/or
	Scilab/Scicos/CodeGen, addressed as SCICOS:
	- in a local/remote/distributed way,
	- by monitoring their local/remote/distributed execution,
	- by changing their parameters on the fly for performance supervision,
	  monitoring, tuning and optimisation.

config RTAI_EFLTK_DIR
	depends on RTAI_LAB
	string "EFLTK installation directory"
	default "/usr/local/efltk"
	help

	You need the Extended Fast Light Toolkit (EFLTK) to build
	RTAILab. You can set the path to this package's installation
	directory here.

endmenu

source rtai-sim/Kconfig