Jan Kiszka wrote:
attached is an experimental patch to allow blocking from non-RT context
on RTDM events. Petr Cervenka made me think about this extension which
could partially open RTDM drivers also for non-shadowed, i.e. standard
Why not simply shadowing non-RT waiters? Because this kind of sync
support should be cheaper than adding yet another (though low-prio) task
to the real-time domain ("should" == I didn't benchmark my believe). And
I would rather move the logic to the sync object at nucleus level since
it's a useful feature for all skins, but doing so, we would also drag a
fair amount of complexity just for the sake of not having to shadow a
Linux task. IMHO, leaving this at the skin level forks the
implementation of the synchronization management, which raises the issue
of duplicating functionalities only depending on the calling context.
Looking at the issue differently, we already know that we could shadow
SCHED_NORMAL/SCHED_OTHER threads without promoting them to the
SCHED_FIFO class - you actually submitted this patch, and it's waiting
for -rc2 to be released before I merge it into mainline.
Given that, a shadow thread which remains in secondary mode is seen as
suspended by the Xenomai scheduler, which means that the additional
overhead is close to nil (aside of an additional shadow tcb), until it
tries to grab the resource and thus moves to the primary domain, just
for going to sleep.
IOW, I would rather use the allow-non-SCHED_FIFO-shadow patch to allow
regular Linux tasks to pend seamlessly on Xenomai sync objects as true
shadows, and add to the rtdm blocking syscall handler some code that
would transparently promote any calling regular task as a Xenomai shadow
on the fly, before undergoing the request. The other advantage of such
approach is that the non-RT pending task is still known from the Xenomai
sub-system (/proc/xenomai/ interface and so on), which may be useful
given that it interacts with it. You could still apply a FIFO pending
order with mixed RT and non-RT tasks the same way.
Moving RTDM to native preemption would also be simpler, since RTDM would
expect the issue to be handled at core level directly, and in the
preempt-rt case, the issue of the caller's domain is actually a non-issue.
Xenomai-core mailing list