- 19 Jan, 2021 5 commits
-
-
Philippe Gerum authored
No more in-tree users. Signed-off-by:
Philippe Gerum <rpm@xenomai.org> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com>
-
Philippe Gerum authored
APCs are gone, drop the related machine-specific data. Signed-off-by:
-
Philippe Gerum authored
Directly use a virtual/synthetic IRQ for kicking the deletion procedure for RTDM file descriptors, dropping the dependency on APCs. Signed-off-by:
-
Philippe Gerum authored
Directly use a virtual/synthetic IRQ for waking up the export/unexport procedure, dropping the dependency on APCs. Signed-off-by:
-
Philippe Gerum authored
This patch starts a series aiming at dropping the (functionally redundant) APC interface entirely. APCs are a relic from the Dark Ages, with no upside compared to open coded requests triggering virtual/synthetic IRQs to be handled by the root domain. As a matter of fact, an APC does run as a client handler of a synthetic IRQ under the hood. With this change, all APCs will not be multiplexed over a single synthetic IRQ anymore but each deferred procedure is going to be assigned its own synthetic IRQ channel, which is hardly a problem since we only have a couple of APCs to deal with, much fewer than the number of synthetic IRQs available to us. As a result, /proc/xenomai/apc will not be available for inspecting the trigger count of synthetic interrupts used by the core anymore. Since the I-pipe is on its way out, having this obscure feature dropped in this context seems acceptable. However, the related information will still be available to Dovetail-based builds directly from /proc/interrupts, as synthetic IRQs are (mostly) regular interrupts there. Start with using a virtual/synthetic IRQ for kicking the wakeup procedure for message pipes, dropping the dependency on APCs. Signed-off-by:
-
- 11 Jan, 2021 8 commits
-
-
Jan Kiszka authored
Addresses "warning: cast from pointer to integer of different size". Signed-off-by: -
Philippe Gerum authored
The I-pipe and Dovetail differ only marginally with respect to syscall handling. Abstract only the few details we need to cope with both interfaces. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Dovetail comes with built-in support for proxy tick device management, which enables a client core to grab control over the timer hardware based on the common clockevents abstraction. Once Dovetail's proxy tick device is declared to the common clockevent device layer, all timing requests issued by the in-band kernel for programming timer shots and controlling the device are transparently redirected to the real-time core for handling. The legacy ipipe_timer interface needs to move to the I-pipe section. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Dovetail exports integrated services for proxying the host tick, which requires no specific interface for managing the hardware timer beyond the common clockevents interface. Likewise, the monotonic and realtime clocks can be read directly from the out-of-band stage via the regular kernel calls available from NMI context (ktime_get_mono_fast_ns(), ktime_get_real_fast()). Move the related support to the I-pipe section, we won't need it for Dovetail. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
We may be able to build against a Dovetail-enabled kernel at some point, so do not force-enable CONFIG_IPIPE, it might not be there. At this chance, remove obsolete internal switches and conditions. All I-pipe implementations depend on the GENERIC_CLOCKEVENTS framework, and support for the legacy I-pipe V1 API is long gone. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
This interface is pointless with Dovetail whose applications directly refer to the wallclock time exported through the common vDSO. No functional change is introduced. Signed-off-by:
-
- 08 Jan, 2021 7 commits
-
-
Philippe Gerum authored
The I-pipe and Dovetail share the very same concept of out-of-band, high-priority IPI, but using a different interface. Let's abstract the calls manipulating those IPIs to make them pipeline-specific. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
ipipe_root_p, !ipipe_root_p belong to the I-pipe jargon. Dovetail uses running_inband(), running_oob() for the same purpose instead. Replace all occurrences of ipipe_root_p found in generic code with is_primary_domain(), is_secondary_domain(), which in turn map to the proper predicates depending on the underlying pipeline flavour. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Dovetail implements two types of locks: hard, and hybrid ones. See https://evlproject.org/dovetail/pipeline/locking/ for details. Cobalt is interested in using Dovetail's hard_spinlock_t locks, which are strictly equivalent to the ipipe_spinlock_t locks. Provide a wrapper mapping a generic hard lock to the proper implementation depending on the underlying pipeline flavour. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Unlike the I-pipe, Dovetail comes with no specific tracer, tracepoints can be sent to common ftrace-based tracers, with the 'function' tracer reporting Dovetail-specific information such as the current execution stage, and the real & virtual interrupt states (hard disabled/enabled, stalled/unstalled) for the current context. In other words, ftrace's 'function' tracer with Dovetail is similar to the I-pipe specific tracer. Since we can use ftrace through the regular kernel interface with Dovetail, the legacy trace interface can move to the I-pipe section. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Dovetail enables the regular irq_work() for submitting work from the out-of-band stage (primary mode) to the in-band one (secondary mode). We won't need APCs in the Dovetail case, let's move this code to the I-pipe section. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
The I-pipe and Dovetail access the per-thread information block differently. Abstract this kernel interface. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
Although there are significant commonalities between the I-pipe and Dovetail when it comes to dealing with synchronous kernel events, there is no strict 1:1 mapping between the two kernel interfaces. As an initial step, move all the code handling the kernel events to the I-pipe section. We may exploit commonalities between the I-pipe and Dovetail in this area as we gradually merge support for the latter. No functional change is introduced. Signed-off-by:
-
- 17 Dec, 2020 3 commits
-
-
Philippe Gerum authored
The way we request and manage interrupts depends on the underlying pipeline interface. As a matter of fact, Dovetail already deals with most of the logic implemented by the xnintr layer, such as edge/level shared IRQs, fully reusing the regular genirq interface for management. IRQ handlers with Dovetail have regular signatures as well. For the time being, let's move the entire xnintr layer to the I-pipe specific section created earlier. We should be able to design the abstract interface to IRQ management after this layer for the most part, which we would connect to Dovetail eventually. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
This is the initial step to enabling Dovetail for the Cobalt core, which requires to introduce an abstraction layer between such core and the interrupt pipeline interface, either Dovetail or the legacy I-pipe. Eventually, the Cobalt implementation which has to interface to the underlying pipeline should branch off at the following points: - kernel/cobalt/{ipipe, dovetail}/arch, the arch-specific implementation which overwhelmingly depends on the pipeline flavour. - kernel/cobalt/{ipipe, dovetail}, the generic Cobalt code calling pipeline services. - kernel/cobalt/include/{ipipe, dovetail}, the client glue types and definitions pulled into some basic kernel types by the pipeline implementation (e.g. the thread_info extension structure). - include/cobalt/kernel/{ipipe, dovetail}, the generic Cobalt headers depending on services and definitions the pipeline provides for. We start the process by abstracting the machine-level init code which depends on the pipeline flavour. No functional change is introduced. Signed-off-by: -
Philippe Gerum authored
raw_smp_processor_id() has been callable from any pipeline domain for many moons now, there is no point in using the legacy ipipe_processor_id() call anymore. Signed-off-by:
-
- 16 Dec, 2020 3 commits
-
-
François LEGAL authored
The RTNET sendmsg/recvmsg protocol handlers used to call copy_to/from_user on the struct user_msghdr argument. The syscall entry code already does this copy, so calling again the copy_to/from_user in handlers triggers SPECTRE mitigation protection on ARM. This patch removes the calls in the handlers. This patch has not been tested Signed-off-by:
François LEGAL <devel@thom.fr.eu.org> [Jan: massage commit log] Signed-off-by:
-
François LEGAL authored
The RTNET sendmsg/recvmsg protocol handlers used to call copy_to/from_user on the struct user_msghdr argument. The syscall entry code already does this copy, so calling again the copy_to/from_user in handlers triggers SPECTRE mitigation protection on ARM. This patch removes the calls in the handlers. This patch has not been tested Signed-off-by:
-
François LEGAL authored
The RTNET sendmsg/recvmsg protocol handlers used to call copy_to/from_user on the struct user_msghdr argument. The syscall entry code already does this copy, so calling again the copy_to/from_user in handlers triggers SPECTRE mitigation protection on ARM. This patch removes the calls in the handlers. This patch has been tested with 4.4.x kernel Signed-off-by:
-
- 14 Dec, 2020 4 commits
-
-
Philippe Gerum authored
No point in abstracting xnclock_get_host_time() and actually counter-intuitive since it refers to the host-managed wallclock time, not to any Xenomai-controlled clock device. Fix the single in-tree user and drop this call. Signed-off-by:
-
Philippe Gerum authored
__ipipe_serial_debug() is a legacy wrapper to the current raw_printk() service. Drop the last in-tree reference to this obsolete call. No functional change is introduced. Signed-off-by:
-
Philippe Gerum authored
We have no architecture enabling this feature anymore. Signed-off-by:
-
Philippe Gerum authored
Allowing the task context switching code to be preempted by local interrupts was an optimization targeted at low-end ARM armv4/5 cores with sluggish VIVT caches, at the expense of significant complexity in the IRQ pipeline and Cobalt scheduler. Support for armv4/5 is long gone for Xenomai, and maintaining such feature is not worth the burden with the VIPT caches exhibited by current micro-architectures such as armv7. Dovetail provides some form of preemptible context switching of in-band tasks specifically, which requires no support from Cobalt. So we may disable this Cobalt-specific feature entirely for ARM. Signed-off-by:
-
- 11 Dec, 2020 7 commits
-
-
Philippe Gerum authored
Concurrent timer start vs start, or start vs stop operations may end up confusing the logic, like: - a periodic timer being reinserted into the dispatch queue while disabled. - dirty reads of inconsistent ( date, interval, handler ) triplets by the dispatch loop, as the timer properties are being updated concurrently. Fix this by moving all updates to the timer properties under the protection of the dispatch lock (svlock), likewise for loads. Issue reported by Ronny Meeus, with a preliminary fix: https://xenomai.org/pipermail/xenomai/2020-December/043907.htmlSigned-off-by:
-
Philippe Gerum authored
Signed-off-by:
-
Philippe Gerum authored
We have no more in-tree users of these. Besides, let's assume that the CPU's branch predictor always has better clues than we might have when assessing the likeliness of a condition. Bonus: this clears a recurring source of namespace clashes with C++ frameworks like Boost. Signed-off-by:
-
Philippe Gerum authored
In user-space at least, we'd be better off trusting the CPU's branch predictor, instead of relying on our limited perception when it comes to determining the likeliness of a condition, or every compiler to do the right thing with respect to efficient branching. We only have a few unlikely predictions in-tree on straightforward conditions, which we can remove safely: - POSIX condvars wait/signal loops on x86, arm and arm64 showed no observable performance penalty. - other callers from the thread cancellation path, or debug instrumentation are slow paths in essence anyway. Signed-off-by:
-
Philippe Gerum authored
We want to wait for ^C or any hangup condition received from the root stage, make sure to annotate as __STD(sigwait()) to bypass symbol wrapping. Signed-off-by:
-
Philippe Gerum authored
Uninstall udev rules. Signed-off-by:
-
Jan Kiszka authored
We migrated to gitlab-ci now, and the travis script will only bitrot over the time. Signed-off-by:
-
- 17 Nov, 2020 2 commits
-
-
Florian Bezdeka authored
The feature initialization was arch specific up to now and the available features (= features offered by the currently running kernel) were no longer accessible once the bind syscall finished. This patch introduces a simple API for fetching the offered features during runtime. Signed-off-by:
Florian Bezdeka <florian.bezdeka@siemens.com> [Jan: simplify cobalt_features_available] Signed-off-by:
-
Florian Bezdeka authored
cobalt_check_features is implemented for each architecture. As further feature initialization will arrive the name of the function should clarify that. Signed-off-by:
-
- 12 Nov, 2020 1 commit
-
-
Florian Bezdeka authored
Updating to upstream revision f858275f7f307eecba84c2f5429483f9f28007f8. Upstream repository is located at [1]. The reason for updating was the following compiler error when trying to compile with GCC 10.2 10.2.1 20201016. As it turned out the problem was already addressed upstream: iniparser/iniparser.c: In function ‘iniparser_load’: iniparser/iniparser.c:616:13: error: ‘sprintf’ arguments 3, 4 may overlap destination object ‘buf’ [-Werror=restrict] 616 | sprintf(tmp, "%s:%s", section, key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I reviewed especially the API changes. Most of them are cleanups only but two things should be pointed out: - The type of the size field of struct _dictionary_ changed from int to ssize_t. The only user of this struct is lib/analogy/calibration.c which uses this structure for internal things only. It is never exposed to any public API so updating is OK and fully backward compatible. - dictionary_new changed its signature from dictionary_new(int size) to dictionary_new(size_t size). This function is not part of any public API. So updating does not break backward compatibility. [1] https://github.com/ndevilla/iniparserSigned-off-by:
-
