/
Kconfig
572 lines (514 loc) · 23.5 KB
/
Kconfig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
# Copyright (C) 2005-2017 The RTAI project
# Copyright (C) 2019 Alec Ari <neotheuser@ymail.com>
# This [file] is free software; the RTAI project
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
mainmenu "RTAI/x86 configuration"
config MODULES
bool
default y
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 "/lib/modules/$(uname -r)/build"
help
This variable contains the directory of your previously
patched Linux kernel. As explained before, you can change the
value of the Linux source tree which is fixed by default to
/lib/modules/$(uname -r)/build.
endmenu
menu "Machine (x86)"
config RTAI_CPUS
string "Number of CPUs (SMP-only)"
default 8
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.
The default value is 8.
config RTAI_DIAG_TSC_SYNC
bool "Diagnose out of sync multi processor TSCs"
default n
help
Check the alignment of multi processor TSCs against a master CPU.
Display them in the RTAI HAL proc file system (in nanosecs).
To check if it is an option worth having, insmod just rtai_hal.ko
and type "cat /proc/rtai/hal", to see how much the TSCs are skewed
with respect to the chosen master CPU.
If you want to use them to correct any bias enable RTAI_TUNE_TSC_SYNC
also.
config RTAI_MASTER_TSC_CPU
depends on RTAI_DIAG_TSC_SYNC
string "Define the master CPU for aligning MP-TSCs"
default 0
help
Master CPU to use to diagnose and, possibly, correct, if RTAI_TUNE_TSC_SYNC
is set, TSC (mis)alignments.
config RTAI_TUNE_TSC_SYNC
depends on RTAI_DIAG_TSC_SYNC
bool "Tune out of sync MP-TSCs"
default n
help
Use offsets made available by enabling the out of sync diagnosis to
keep readings of TSC times as aligned as possible.
endmenu
menu "Base system"
menu "Scheduling options"
config RTAI_SCHED_ISR_LOCK
bool "Disable immediate rescheduling from within 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 believed to be 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 wanting to have any awaken higher priority task scheduled only
after exiting the ISR, regardless from where a scheduling API is
called within the handler, should disable immediate rescheduling
from ISRs by enabling this configuration option.
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_USE_STACK_ARGS
bool "Keep using RTAI way for user-kernel space on stack args exchange."
default n
help
When it is sure that RTAI syscalls args, to be copied between user-kernel
space, are on the stack, RTAI uses kernel space memcopy, instead of the
various canonical copy from-to user. Such a scheme, quite simple and
effective, has worked for almost two decades without any glitch.
Unfortunately, recent CPUs, likely from Ix-6xxx onward, segfault with it,
forcing RTAI to comply with the canonical way.
The related trouble can be easily spotted at the very first rtai_sched.ko
usage, i.e. when the very first latency calibration is carried out (see
the related parameter helps), when the core dump summary, as read with dmesg,
shows a segfault at lxrt_intercept_syscall.
Nonetheless, such a way can still be a useful choice and may not cause any
trouble with recent ATOMs and CELERONs.
Thus, this parameter, defaulting to a safer no, let the user have a choice
anyhow.
config RTAI_LATENCY_SELF_CALIBRATION_METRICS
string "Lat. cal. metrics: 1- AVRG (default), 2- LEAST, 3- (AVRG+LEAST)/2"
default 1
help
This parameter sets the latency calibration criteria.
1 - AVERAGE will provide mostly zero averages, but possible oscillations
below zero could be significant.
2 - LEAST VALUE should be chosen for average values being only marginally
less than zero.
3 - (AVERAGE + LEAST_VALUE)/2, a trivial compromise in between the previous
two.
config RTAI_LATENCY_SELF_CALIBRATION_FREQ
string "Latency self calibration frequency (Hz)."
default 10000
help
In order to be on time, as finely as possible, RTAI anticipates the
next scheduling shot of the hard timer clock interrupt by an amount
of time aimed at compensating the programming overhead spent in
the context switch and to set the right firing time.
Such an amount is determined with the calibration support provided
by RTAI itself, both for kernel and user space tasks.
The calibration procedure is applied on the fly the first time
rtai_sched.ko is insmoded, by launching, in series, a calibrating
kernel and user space task. That will, typically, happen when any
latency test, of the the testsuite which comes with RTAI, is used
to verify its installation.
The present parameter sets the calibration frequency, while another
one defines the number of loops to be spent for calibrating.
The calibration results are saved in
"rtai-installdir/calibration/latencies", where "rtai-installdir" is
the RTAI installation directory defined when configuring RTAI.
Such a file is used in any following insmod of the RTAI scheduler, so
that no further recalibration will be carried out.
Nevertheless, new recalibrations can be forced anyhow, either through
"rm rtai-installdir/calibration/latencies" or through
"insmod rtai-installdir/modules/rtai_sched.ko recalibrate=1".
At the very first rtai_sched.ko insmoding, after delating the
latencies file or after insmoding rtai_sched.ko with "recalibrate=1",
you should be prepared to wait for approximately twice the calibration
time required to carry out the number of requested calibrated loops.
Such a procedure should allow appropriate latency calibrations also
when cross development and embedding is needed.
Use a frequency that is close to your range of interest. Because of
cache warming, lower frequencies will tend to anticipate the scheduling
when higher ones are used and viceversa.
If valuable calibrated values are available, they can be used to
substitute those obtained by calibrating, through rtai_sched.ko
parameters "kernel_latency" and "user_latency", in nanos, either any
single one or both, e.g: "insmod rtai_sched.ko user_latency=4000".
A further way to modify the scheduling latencies is to edit the first
two fields of "rtai-installdir/calibration/latencies", kernel and
user space respectively, likely the simplest and speediest mode.
config RTAI_LATENCY_SELF_CALIBRATION_CYCLES
string "Number of latency self calibration cycles."
default RTAI_LATENCY_SELF_CALIBRATION_FREQ
help
In order to be on time, as finely as possible, RTAI anticipates the
next scheduling shot of the hard timer clock interrupt by an amount
of time aimed at compensating the programming overhead spent in
the context switch and to set the right firing time.
Such an amount is determined with the calibration support provided
by RTAI itself, both for kernel and user space tasks.
The calibration procedure is applied on the fly the first time
rtai_sched.ko is insmoded, by launching, in series, a calibrating
kernel and user space task. That will, typically, happen when any
latency test, of the the testsuite which comes with RTAI, is used
to verify its installation.
The present parameter sets the number of calibration cycles needed
for obtaining a stabilized results, while another one defines the
calibration frequency.
Use a number of cycles appropriate to allow an adequate number of
reschedules. If the calibration is carried out in a "calm" environment,
strongly suggested, there is no need to exceed a few seconds. In any
case, it is done just once, or when you will force it again.
Nonetheless, it should be remarked that the calibration precedure,
based on a Kalman filter, checks its convergence, exiting at once
when the calibration tolerances are met. Therefore it is quite
possible that the related procedure will be faster than expected,
i.e. it will use less that the requested cycles.
The calibration results are saved in
"rtai-installdir/calibration/latencies", where "rtai-installdir" is
the RTAI installation directory defined when configuring RTAI.
Such a file is used in any following insmod of the RTAI scheduler, so
that no further recalibration will be carried out.
Nevertheless, new recalibrations can be forced anyhow, either through
"rm rtai-installdir/calibration/latencies" or through
"insmod rtai-installdir/modules/rtai_sched.ko recalibrate=1".
At the very first rtai_sched.ko insmoding, after delating the
latencies file or after insmoding rtai_sched.ko with "recalibrate=1",
you should be prepared to wait for approximately twice the calibration
time required to carry out the number of requested calibrated loops.
Such a procedure should allow appropriate latency calibrations also
when cross development and embedding is needed.
Use a frequency that is close to your range of interest. Because of
cache warming, lower frequencies will tend to anticipate the scheduling
when higher ones are used and viceversa.
If valuable calibrated values are available, they can be used to
substitute those obtained by calibrating, through the rtai_sched.ko
parameters "kernel_latency" and "user_latency", in nanos, either any
single one or both, e.g: "insmod rtai_sched.ko user_latency=4000".
A further way to modify the scheduling latencies is to edit the first
two fields of "rtai-installdir/calibration/latencies", kernel and
user space respectively, likely the simplest and speediest mode.
config RTAI_KERN_BUSY_ALIGN_RET_DELAY
string "Delay to return to a switched in timed kernel task (ns)"
default 0
help
The average time to return to the timed calling function after
switching back to a kernel space task.
It is subtracted from the resume time of a timed task to avoid
a delayed return when a busy wait to align to the resume time is
assigned by setting this parameter to a value > 0.
A <= 0 value will skip the busy alignment.
Useful to allow the alignment application just for kernel tasks.
For example when a precise calibration for user space is used, a
kernel task will anticipate its timed resumption; so setting a
positive value here and a <= 0 busy wait time for the corresponding
user space option will allow applying the busy wait just to kernel
tasks.
config RTAI_USER_BUSY_ALIGN_RET_DELAY
string "Delay to return to a switched in timed user task (ns)"
default 0
help
The average time to return to the timed call function after switching
back to a user space task.
It is subtracted from the resume time of a timed task to avoid
a delayed return when a busy wait to align to the resume time is
assigned by setting this parameter to a value > 0.
A <= 0 value will skip the busy alignment.
Usually it is not needed if the RTAI_SCHED_LATENCY has been calibrated
in user space.
config RTAI_SCHED_LXRT_NUMSLOTS
string "Number of registrable RTAI objects"
default 256
help
The maximum number of registrable objects in RTAI.
The default value is 256.
config RTAI_MONITOR_EXECTIME
bool "Display RTAI task execution time (in 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_FULL_PRINHER
bool "Enable full priority inheritance"
default n
help
In RTAI resource semaphores, aka mutexes, support two ways to
manage priority inheritance, both for resource semaphores and
intertask messages, blocked sent or rpced, to a task owning any
resource semaphore already. Notice in fact that the task itself
becomes a kind of "de facto" resource when any task blocks on it
to exchange messages.
Without enabling this option a task owning any resource will
recover its base priority only when it releases the very last
resource it owns. So full priority inheritance will work as
it is usually expected for a singly owned resource only because,
whenever a task achieves the ownership of more than one resource,
priority inheritance will become an adaptive dynamic priority
ceiling. In such a case in fact the task priority is increased
according to the highest priority task waiting on any resource
a task owns, itself included because of messages being exchanged
with it, but it will be returned to its base priority only when all
owned resources are released. This is a compromise design choice
aimed at avoiding searches for the new priority to be inherited
across multiply owned resources and blocked tasks send/rpcing to
the task.
By enabling this configuration option instead you'll allow full
priority inheritance, so that when a task releases any resource
semaphore it owns it will acquire the priority of the most prioritary
task, either waiting on any resource semaphore that it is still
owned by the task or blocked send/rpcing to it.
The choice is dependent on your needs mostly. Just take into account
that the default dynamic priority ceiling is simpler, a bit more
effective and less deadlock prone than full priority inheritance.
config RTAI_ALIGN_LINUX_PRIORITY
bool "Keep Linux task priority aligned to RTAI"
default y
help
By enabling this option the RTAI scheduler will keep Linux tasks
execution priority aligned to its. Naturally this makes sense
either for Linux soft real time tasks enabled to use RTAI APIs,
i.e. they issued rt_task_init/rt_task_init_schmod, or when RTAI
hard real time tasks are given back to Linux.
endmenu
menu "Supported services"
config RTAI_FIFOS
tristate "Fifo"
default y
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.ko
Must be enabled as a built-in (Y) for LinuxCNC.
config RTAI_SHM
tristate "Shared memory"
default y
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.ko
Must be enabled as a built-in (Y) for LinuxCNC.
config RTAI_SEM
tristate "Semaphores"
default y
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.ko
Must be enabled as a built-in (Y) for LinuxCNC.
config RTAI_RT_POLL
bool "Enable IPCs polling"
depends on RTAI_SEM
default n
help
This enable polling support for RTAI services. At the moment only
MBXes and SEMs are supported. The related service is embedded in
the semaphores module.
config RTAI_RT_POLL_ON_STACK
bool "Use the stack for rt_poll dynamic arrays"
depends on RTAI_RT_POLL
default n
help
This let rt_poll allocate its dynamic data directly on the stack. It is
likely the most effective way but it can deplete the stack somewhat,
especially on 64 bits architectures, if polling requests are large,
say > 40. Notice that even with smaller polling sizes it might be
important to limit stack usage also when heavy preemptions, very high
task switching rates and interrupts flooding are expected.
By disabling this parameter RTAI will use its real time memory
allocation; with it the limits are just in the size you set for the
RTAI dynamic heap and in a slightly greater overhead. So for reasons
of cautiousness the default setting is not to use the stack.
config RTAI_MSG
tristate "Message"
default m
help
Direct synchronization by direct intertask messaging, either as fast
single unsigned long messages or as extended arbitrarily sized
messages. Both async and sync messages with replies can be used.
QNX styled APIs are also available. Blocking messages exploit priority
inheritance, which becomes a dynamic ceiling when inheritances are
mixed with resource sems.
The module will be called: rtai_msg.ko
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.ko
config RTAI_CLOCK_REALTIME
bool "Support for Posix CLOCK_REALTIME APIs"
default y
help
The purpose here is mainly to activate the CLOCK_REALTIME timing
support in a few RTAI native services used behind POSIX APIs.
CLOCK_REALTIME is the default POSIX timing option so it should be
enabled for a full POSIX support but, if you are either not using
POSIX or can work with it using just the CLOCK_MONOTONIC timing,
it would be better to avoid enabling this option. It will save you
a test on a long long. Not too much of an overhead indeed, but why
paying for it if not needed?
It is defaulted to "yes" just to stay on the safe side.
endmenu
menu "Other features"
config RTAI_USE_NEWERR
bool "New return values of blocking RTAI APIs"
default y
help
Return values for RTAI blocking APIs are a bit sketchy. That
is due to a long standing legacy dating back to DOS and 8 bits PCs,
when saving a few "if"s might have been important. Whatever one's
opinion such a legacy has now been likely inherited by many well
working existing RTAI applications, that might break with a new
error return scheme. In any case a better set of error return values
might be useful nowadays, so it has been added. With it one will be
able to correctly infer more detailed reasons for error returns i.e.:
- invalid requests (RTE_OBJINV),
- async unblocking (RTE_UNBLKD),
- timeouts (RTE_TIMOUT),
- timer overruns (RTE_TMROVRN),
- deletion of blocking objects (RTE_OBJREM).
Thus the new scheme has been made configurable to allow RTAI users
to choose what to do, without forcing any adaption for already
existing working applications.
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 free memory safely while executing
in the real-time domain. If it is not enabled kernel's kmalloc will
be used. So disabling this option is acceptable if you'll care
to do any allocation while in Linux context only, i.e. at modules
initialisation.
The module will be called: rtai_malloc.ko
config RTAI_USE_TLSF
bool "Allocate memory using TLSF in place of BSD one"
depends on RTAI_MALLOC
default n
help
RTAI dynamic memory allocation support offers two different methods
to allocate memory chunks. The default one is along the lines
illustrated in:
"Design of a General Purpose Memory Allocator for the 4.3BSD Unix
Kernel" by Marshall K. McKusick.
By enabling this option the:
"Two Levels Segregated Lists (TLSF)" as found at:
http://rtportal.upv.es/rtmalloc/allocators/tlsf/
will be used instead.
Rough measures seems to indicate small differences between the two
in term of alloc/free times, likely with BSD being better for the
tested allocation sizes (up to a few KBs), but TLSF seems to have
better, i.e. lower, fragmentation properties. In any case you should
check it yourself within your own applications.
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 soft 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.)
The default value is 2048.
config RTAI_KSTACK_HEAPSZ
string "Size of stacks heap for RTAI own kernel tasks (Kbytes)"
depends on RTAI_MALLOC
default 512
help
RTAI pre-allocates a heap for the stacks of its own kernel tasks.
This parameter allows to define its size (in kilobytes.)
The default value is 512.
config RTAI_TASK_SWITCH_SIGNAL
bool "task switches specific signal"
default n
help
RTAI can signal a task switch each time a task resumes execution.
The way it is done depends on the execution space:
- kernel: execute a function assigned at rt_task_init or by calling
rt_task_signal_handler;
- user: install an RTAI own signal handler and have it called at any
task switch through its number, assigned by calling
rt_task_signal_handler.
The default is to not make available this feature, so you must enable
it explicitly if it is useful for your application.
endmenu
endmenu