mainmenu "RTAI/x86 configuration"

config MODULES
	bool
	default y

config RTAI_VERSION
	string
	default "3.3 (vulcano)"

menu "General"

config RTAI_INSTALLDIR
	string "Installation directory"
	default "/usr/realtime"

	help
	This option defines the directory where the various RTAI
	files will be installed on your target system.
	This directory may be changed if you double-click in the area
	named "Value". The default installation directory is
	/usr/realtime.

config RTAI_LINUXDIR
	string "Linux source tree"
	default "/usr/src/linux"
	help
	This variable contains the directory of your previously
	patched Linux kernel. As explained before, you can changed the
	value of the Linux source tree which is fixed by default to
	/usr/src/linux.  

menu "RTAI Documentation"

config RTAI_DOX_DOC
	bool "Build RTAI Doxygen documentation (HTML)"
	default n
	help
	This option causes the Doxygen-based RTAI documentation to be
	built. This option is intended for people actually writing
	documentation and who want to update the pre-built manuals,
	regular users can just use the latter directly. You will need
	the Doxygen toolsuite for regenerating the documentation.

config RTAI_DOC_LATEX_NONSTOP
        bool "Enable LaTeX verbose output"
        default n
        help
        By default, all documentation generated with LaTeX uses the 
        silent (batchmode) of LaTeX. If this option is enabled, the 
        verbose (nonstopmode) of LaTeX will be used instead. This 
        option is mainly intended for people writing RTAI 
        documentation.

config RTAI_DBX_DOC
	bool "Build DocBook XML documentation (HTML/PDF)"
	default n
	help
	This option causes the DocBook XML based RTAI documentation to be
	built. This option is intended for people actually writing
	documentation and who want to update the pre-built manuals,
	regular users can just use the latter directly.

config RTAI_DBX_NET
        bool "Let the DocBook XML tools use network"
	depends on RTAI_DBX_DOC
        default n
        help
        Let the DocBook tools use internet to fetch the DTD and XSL stylesheets.
        If disabled, the documentation generation will fail if the necessary 
        DTD(s) and XSL stylesheets can not be found on the local computer.

config RTAI_DBX_ROOT
        string "Docbook XML root"
	depends on RTAI_DBX_DOC
        default ""
        help
        Specify the DocBook XML root (that is, the directory where docbook.dtd
        should be taken). Leave blank to let configure try the "well-known"
        locations.

config RTAI_DBX_XSL_ROOT
        string "Docbook XML XSL stylesheet root"
	depends on RTAI_DBX_DOC
        default ""
        help
        Specify the DocBook XML XSL root. Leave blank to let configure try the
        "well-known" locations.

endmenu

config RTAI_TESTSUITE
	bool "Build RTAI testsuite"
	default y
	help
	Once you are done with the building process of RTAI, it may be
	safe to run the testsuite to make sure your RTAI system is
	functional. However if it does not it is possible that RTAI is not
	the only one to blame, check your kernel config also.

config RTAI_COMPAT
	bool "Enable source compatibility mode"
	default y
	help
	This option allows to preserve the compatibility between
	applications issued from the 24.1.x version of RTAI and the
	3.x branch.  This way, no adaptation in the header files is
	required.

config RTAI_EXTENDED
	bool "Enable extended configuration mode"
	default n
	help
	Allows some configuration parameters in the Hardware
	Abstraction Layer or the schedulers.

config RTAI_KMOD_DEBUG
	bool "Enable debug symbols in modules"
	depends on RTAI_EXTENDED
	default n
	help
	This options adds the -g flag when compiling
	kernel modules.

config RTAI_USER_DEBUG
	bool "Enable debug symbols in user-space programs"
	depends on RTAI_EXTENDED
	default n
	help
	This options adds the -g flag when compiling user-space programs. 
	User space RTAI syscall by simple inlining is implicitely disabled.

config RTAI_MAINTAINER
	bool "Enable maintainer mode"
	depends on RTAI_EXTENDED
	default n
	help

	This option will activate the '--enable-maintainer-mode'
	option in the configure scripts. For more information, refer
	to the autoconf documentation:
	http://sources.redhat.com/autobook/autobook/autobook_26.html#SEC26

config RTAI_MAINTAINER_AUTOTOOLS
	bool "Enable Autoconf/Automake maintainer mode"
	depends on RTAI_MAINTAINER
	default n

choice
	optional
	prompt "Private maintainer profiles"
	depends on RTAI_MAINTAINER

config RTAI_MAINTAINER_NONE
	bool "Use standard settings"

config RTAI_MAINTAINER_PMA
	bool "Use settings from mantegazza()aero!polimi!it"

endchoice

choice
	prompt "Inlining mode of user-space services"
	depends on RTAI_EXTENDED
	help
	Allows choosing among:
	- Conditional inlining: i.e. extern inline, depends on compiler's 
	  optimization switch;
	- Eager inlining:       i.e. static inline, always inline regardless 
	  of compiler's optimization switch;
	- Never inline:         i.e. user-space services are linked to 
	  programs against the appropriate support library (e.g. liblxrt.a 
	  for user space RTAI syscall services).

config RTAI_LXRT_EXTERN_INLINE
	bool "Conditional inlining"
	help

config RTAI_LXRT_STATIC_INLINE
	bool "Eager inlining"
	help

config RTAI_LXRT_NO_INLINE
	bool "No inlining"
	help

endchoice

endmenu

menu "Machine (x86)"

config RTAI_DONT_DISPATCH_CORE_IRQS
	bool "Direct vectoring of RTAI native interrupts"
	depends on RTAI_EXTENDED
	default y
	help
	RTAI dispatches real time interrupts immediately to achieve as
	low a overhead as possible. Very important on low end CPUs. By
	setting this option it is possible to achieve a further improvement
	by allowing hard RTAI internal timers and SMP interprocessor 
	scheduling interrupts to be vectored directly to their handlers, 
	i.e without any dispatching overhead. A must on low end CPUs.

config RTAI_FPU_SUPPORT
	bool "Enable FPU support"
	default y
	help
	The FPU executes instructions from the processor's normal
	instruction stream. It can handle the types of high-precision
	floating-point processing operations commonly found in
	scientific, engineering, and business applications.  Enabling
	FPU support on a platform providing this hardware component
	may greatly improve performances.  You can obtain more
	information about Float-Point Unit on i386 platform on
	internet at the following URL:
	http://www.intel.com/design/intarch/techinfo/Pentium/fpu.htm

config RTAI_CPUS
	string "Number of CPUs (SMP-only)"
	default 2
	help
	RTAI has native support for Symmetrical Multi-Processing
	machines. If it is your case, you may want to enter here the
	number of CPUs of your motherboard.

	PAY ATTENTION: the default value is 2.

endmenu

menu "Base system"

config RTAI_SCHED_LXRT_
	bool "Kernel/User space scheduler without RTAI own kernel tasks (KEEP)"
	default y
	help
	This scheduler supports hard real time for all Linux schedulable
	objects, i.e. processes/threads/kthreads. All of RTAI APIs are 
	available simmetrically inter/intra kernel and user space.

	This configuration parameter is ignored by the build process and
	this scheduler will be made anyhow, along with the related liblxrt.

config RTAI_KTASKS_SCHED_LXRT_
	bool "Kernel/User space scheduler with RTAI own kernel tasks (KEEP)"
	default y
	help
	After enabling this option, the scheduler supports not only hard
	real time for all Linux schedulable objects, i.e.
	processes/threads/kthreads, but also for RTAI own kernel tasks.

	A secondary effect is that rt_task_init() will generate RTAI
	own kernel tasks instead of real time hardened Linux kernel threads.
	This will reduce task switching time, with noticeable effects on
	low end CPUs.

	Users wanting to use both RTAI own tasks and real time hardened
	Linux kernel threads must specifically use rt_task_init for the 
	former and rt_thread_init for the latter.

	This configuration parameter is ignored by the build process and
	this scheduler will be made anyhow, along with the related liblxrt.

menu "Scheduler options"

	depends on RTAI_EXTENDED

config RTAI_SCHED_ISR_LOCK
	bool "Disable rescheduling from ISRs"
	default n
	help
	RTAI schedules as soon as a higher priority task is awaken in an 
	interrupt handler, i.e. it does not wait to exit the handler itself.
	This is the best way since a user that does not want it has just to
	care calling any scheduling API at the very end of her/his handler.
	Those not wanting to care when/where to call any scheduling API in
	their handler should enable this options to be happy.

config RTAI_RTC_FREQ
	string "Set RTC clock tick frequency and use RTC as the only timer"
	default 0
	help
	1 - Are you happy of working in periodic mode?
	2 - If so, is it accepable to resolve your timing needs with a 
	    tick within a frequency that can be varied just in powers of
	    2, from 2 to 8192 Hz?
	If both your answers are YES than it might be worth setting your 
	tick frequency of choice here and let RTAI schedulers work with 
	it using the Real Time Clock (RTC). Be careful though as:
	- you must not have configured the RTC as available to Linux;
	- RTC will be the only available timer and its tick frequency 
	  can be modified only here, so you must reconfigure this param 
	  to change it, setting it to zero to return using the other 
	  RTAI timers.
	The main advantage of using the RTC, if constraints 1 and 2 can be
	accepted, is that you will not touch any of the hard timing sources
	used by Linux (8254 especially and APIC too). In fact if an APIC 
	timer is available (SMP and recent machines) it is possible to avoid
	the most important interference with Linux timing by not using the 
	8254. However such a possibilty is not available on low end CPUs 
	and embedded systems for which the only way to avoid interfering with
	the Linux timer might be this option. Thus in such cases, 1-2 above 
	being acceptable once more, setting this config param might be a
	good choice.

config RTAI_LONG_TIMED_LIST
	bool "Use a binary tree ordering for RTAI schedulers timed lists."
	default n
	help
	RTAI schedulers use a simple ordered linear list for suspended timed
	tasks by default. By enabling this option a binary sort type ordering 
	is used. Such a scheme requires far less, albeit far more complex, 
	operations to set up a time ordered list of wake up times. So when 
	one has not so many tasks on the timed lists this option might not 
	be worth having. The actual threshold value depends on many factors,
	CPU power being the main one. So it is up to you to make a choice.
	If you have many tens or even hundred(s) of timed tasks then it is 
	likely that it might be worth enabling this option.

config RTAI_SCHED_8254_LATENCY
	string "8254 tuning latency (ns)"
	default 4700
	help
	The anticipation time to be used to program the hard timer, in oneshot
	mode, for the next scheduling shot in order to compensate for the 
	programming overhead needed to determine the right firing time.
	This parameter has no effect when the periodic mode is used.

config RTAI_SCHED_APIC_LATENCY
	string "APIC tuning latency (ns)"
	default 3944
        help
        The anticipation time to be used to program the hard timer, in oneshot
        mode, for the next scheduling shot in order to compensate for the
        programming overhead needed to determine the right firing time.
	This parameter has no effect when the periodic mode is used.

config RTAI_SCHED_LXRT_NUMSLOTS
	string "Number of registrable RTAI objects"
	default 100
	help
	The maximum number of registrable objects in RTAI.

config RTAI_MONITOR_EXECTIME
	bool "Display RTAI task execution time (per thousand)"
	default y
	help
	If this option is enabled it is possible to see the time consumed by
	hard real time tasks, in per thousand of the total time available, 
	by using the RTAI scheduler proc file, e.g. "cat /proc/rtai/scheduler".
	Since this option uses the TSC it is better to avoid it in production
	for x86 CPUs not having TSCs, i.e. 486s and some untrue 586s.

config RTAI_ALLOW_RR
	bool "Allow round-robin scheduling"
	default y
	help
	By enabling this option it is possible to use round robin scheduling
	in RTAI, after enabling such a mode on a task by task basis through a
	call to a suitable scheduler function.

config RTAI_ONE_SHOT
	bool "One-shot timer mode"
	default n
	help
	Set to enable one-shot timer mode as the default. If not set, the 
	hard timer will run in periodic mode according to the period used 
	in start_rt_timer().
	Notice that whatever the default setting chosen it is possible to
	override it by specifically calling either rt_set_oneshot_mode() or 
	rt_set_periodic_mode() at run time.

config RTAI_BUSY_TIME_ALIGN
	bool "Busy wait to ensure resume time alignment"
	default n
	help
	In oneshot mode there is a calibrated anticipation of the timer
	firing to compensate for the time consumed in scheduling. 
	Sometimes, either because of a bad calibration or purposely, it is
	possibile to anticipate the scheduling by setting a larger than needed
	anticipation. In such cases with this option one can be sure to
	achieve the desired scheduling time at the expense of waisting
	processor time. Useful when there is enough computational power to 
	waist in favour of precise schedule deadlines.
	Do not set it if a hard periodic timer is to be used.

config RTAI_LXRT_USE_LINUX_SYSCALL
	bool "Wrap LXRT service calls through Linux syscall mechanism"
	default n
	help
	With this option enabled, LXRT uses the Linux syscall mechanism
	for service calls, as provided by libc "syscall".  This may improve 
	signal handling (and therefore debugging of LXRT applications), but 
	has the drawback of a slight overhead. 

	When direct inlining of RTAI syscalls is enabled, see the related
	configuration options, it is still possible to force the use of 
	the Linux syscall mechanism, even if this configuration parameter 
	has not been set. The only thing to do is to add:
	#define USE_LINUX_SYSCALL
	before any RTAI header inclusion, in any source file in which you
	want to use the Linux syscall mechanism. In the same way when this
	parameter is set you can selectively revert to LXRT own syscall
	mechanism by defining:
	#undef USE_LINUX_SYSCALL
	before any RTAI header inclusion, in any source file in which you
	want to use the LXRT syscall mechanism.
	RTAI will then operate in mixed mode selectively by using both 
	its own and Linux syscall mechanisms.
	
	If in doubt, say no.

config RTAI_CAL_FREQS_FACT
	string "Cure loosely calibrated frequencies - see help"
	default 0
	help
	In oneshot mode using the APIC timer, i.e. always for SMP, a precise 
	scheduling time depends also on the ratio cpu_freq/apic_freq. The best
	results can be achieved by using the RTAI calibration tool. 
	If no calibration is run one will rely on what Linux makes available 
	by default, which could be not precise enough, especially for not so 
	short timed intervals.
 	That leads to large and systematic latencies, especially in the case
	of low frequency schedules. By setting this option to a suitable
	value one can be sure that a certain firing frequency is granted 
	even when relatively large idle periods are enconuntered, thus
	limiting the overall latency with which long sleeping tasks might
	be awaken in case of unprecise calibrations of the above cited
	frequencies. The granted firing interval will be roughly equal to:
	1.0/(RTAI_CAL_FREQS_FACT + 2.0) (seconds).

endmenu

menu "Supported services"

config RTAI_BITS
	tristate "Event flags"
	default m
	help
	Event flags are used to synchronize a task to the occurrence of 
	multiple events. RTAI ues the term "bits" to stress the fact that
	events are just logical objects, i.e. a kind of digital I/O, 
	nothing else being associated to them, e.g a count. 
	So any synchronization based on them may be disjunctive, when any 
	of the events have occurred, or conjunctive, when all events have 
	occured. The former corresponds to a logical OR whereas the latter 
	is associated to a logical AND. Their use is similar to semaphores 
	except that signal/waits are not related to just a simple counter 
	but depends on the combination of set of bits.
	The module will be called rtai_bits.o.

config RTAI_FIFOS
	tristate "Fifo"
	default m
	help
	Originally fifos were used to allow communication between 
	kernel-space modules and user-space application. Even if fifos are 
	strictly no more required in RTAI, because of the native availability 
	of symmetric inter/intra kernel RTAI services, fifos are kept both 
	for compatibility reasons and because they are very useful tools to be
	used to communicate with interrupt handlers only based applications,
	since they do not require any scheduler to be installed.
	The module will be called rtai_fifos.o.

config RTAI_NETRPC
	tristate "Net RPC"
	depends on RTAI_MSG
	default y if RTAI_MSG=y
	default m if RTAI_MSG=m
	help
	RPC means Remote Procedure Call. The NetRPC implementation
	corresponds to a synchronous intertask message passing which
	is the old concept and the basis of microkernels, either
	distributed or not.  Using NetRPC makes from RTAI a
	distributed system, both for kernel and user space
	applications.
	NetRPC depends on a messaging support, if none is provided it relies
	on Linux network services, thus loosing strict real time. See the
	RTNet emulation option.
	The NetRPC module will be called rtai_netrpc.o.

config RTAI_NETRPC_RTNET
	bool "Emulate RTNet"
	depends on RTAI_NETRPC
	default y
	help
	This enable RTNet like usage, using Linux soft networking support,
	even when no RTNet is available. It can be used also when RTNet is
	available. In such a case soft real time RTAI tasks will avoid 
	loading the hard real time networking layer.

config RTAI_SHM
	tristate "Shared memory"
	default m
	help
	This RTAI specific module allows sharing memory inter-intra
	real-time tasks and Linux processes. In fact it can be an
	alternative to the SYSTEM V shared memory. It may also be
	noticed that the services are symmetrical, i.e. the same calls
	can be used both in real-time tasks (within the kernel) and
	Linux processes.
	The module will be called rtai_shm.o.

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
	Direct synchronization by direct interask messaging, either as fast
	single unsigned long messages or as extended arbitrarely sized
	messages. Both async and sync messages with replies can be used.
	QNX styled APIs are also avaible. Blocking messages exploit priority 
	inheritance, which becomes a dynamic ceiling when inheritances are 
	mixed with resource sems.
	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 "RTAI message queues and typed mailboxes"
	depends on RTAI_SEM
	default y if RTAI_SEM=y
	default m if RTAI_SEM=m
	help
	RTAI message queues (msgq) are intertask processor messages that allow 
	exchanging prioritised messages of anysize. Broadcasting of messages
	to all the waiing tasks is also possible.
	Legacy typed mailbox (TBX) services are recovered by using RTAI msgqs
	and afford a precanned example of their use offering:
	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 Posix 1003.1d. 
	They provide kernel-safe message queues. Message queues depend on 
	semaphores.
	The module will be called rtai_mq.o.

config RTAI_TASKLETS
	tristate "Tasklets and async signals"
	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, needing to
	execute specific functions. 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
	depending on user defined events. 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.

	Signals are much the same as tasklets and execute their handler
	function whenever they are triggered by any task, including their
	parent task. The notable difference against tasklets is that the
	task they serve is blocked till any of its signal handler is 
	executing. So they behave as standard signal handlers but without
	the need to restart a blocked signalled task, since there is no
	need to have it resumed to catch a signal. In fact signals can be 
	seen as much as software generated interrupts. See their APIs
	documentation in the code.
	The module will be called rtai_signal.o.

	Notice that, if the module version is chosen, this option activates
	the making of two different modules. At the moment the related
	services from user space are seen as LXRT expansions using slots
	1 and 2 respectively.

endmenu

menu "Other features"

config RTAI_MATH
	bool "Math support"
	depends on RTAI_FPU_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_MALLOC
	default y
	help
	RTAI's malloc support offers two different ways to allocate memory 
	chunks, i.e. kmalloc and vmalloc.
	The reasons for using vmalloc:
	- it is simpler to share allocated buffers with user space;
	- it doesn't have the size restrictions of kmalloc.
	The reasons for using kmalloc:
	- it is faster (not important since it as to be used in sof real time);
	- it exhibits contiguous buffer addressing needed for DMA controllers 
	  which don't have scattering/gathering capability.
	The default is using kmalloc()

config RTAI_MALLOC_HEAPSZ
	string "Size of the global heap (Kbytes)"
	depends on RTAI_MALLOC
	default 2048
	help
	RTAI pre-allocates a global heap as part of its initialization
	chores. This parameter allows to define its size (in
	kilobytes).

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
	depends on RTAI_SEM && RTAI_TASKLETS
	default y if RTAI_SEM=y || RTAI_TASKLETS=y
	default m if RTAI_SEM=m || RTAI_TASKLETS=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 "Add-ons"

config RTAI_COMEDI_LXRT
	bool "Comedi support over LXRT"
	default n
	help
	RTAI offers a unified kcomedilib interface to kernel/user space 
	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"
	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_RTDM
	bool "Real-Time Driver Model over RTAI"
	default n
	help
	Real Time Drive Model specific implementation for RTAI.

menu "Drivers"

config RTAI_DRIVERS_SERIAL
	bool "RTAI serial line driver"
	default y
	help
	The RTAI real-time serial driver.
	The module will be called rtai_serial.o.

config RTAI_DRIVERS_16550A
	bool "RTDM base 16550A driver support"
	depends on RTAI_RTDM
	default n
	help
	An alternate RTAI real-time serial driver based on RTDM.
	The module will be called rtai_16550A.o.

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"
	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
