[Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Petr Cervenka]

Hello,
I need to wait in my ioctl handler for an interrrupt. Is it possible to use some rtdm_event_timedwait alternative in non-realtime?
I'm thinking about using wait_event_interruptible_timeout. Is it a good idea or is there a better solution (e.g. rtdm_event compatible))?

Petr Cervenka

Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Petr Cervenka wrote:
> Hello,
> I need to wait in my ioctl handler for an interrrupt. Is it possible to use some rtdm_event_timedwait alternative in non-realtime?
> I'm thinking about using wait_event_interruptible_timeout. Is it a good idea or is there a better solution (e.g. rtdm_event compatible))?

So your interrupt is RT while one of your waiters is non-RT? Then you
have to forward the RT event (i.e. the IRQ occurrence) via an
rtdm_nrtsig_t from the IRQ handler to an nrtsig-event handler in non-RT
context. This handler can then wakeup non-RT waiters.

This may sound a bit complicated, but you have to remind that there is
no safe way to schedule a non-RT (Linux) thread directly from the RT
(Xenomai) domain, because all Linux scheduling services are fully
preemptible by Xenomai at any time (including the RT IRQ handler).

Hmm, as you were asking for a non-RT-safe rtdm_event now: the pattern I
described above might be generalisable to an extended rtdm_event
supporting both RT and non-RT waiters (non-RT wakers already work). Need
to think about this...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Petr Cervenka]

I sense, that there could be a problem. the rtdm_nrtsig_handler_t handler have only one argument (rtdm_nrtsig_t *). But I need to get a pointer to the device and/or the event which has happended and needs to be forwarded to tha waiter.
I hope there is a possibility to search all my devices (usualy one :-)) if the argument belongs to it, and then clear all pending "events" and call wake_up for appropriate wait queues.
But it's not as simple as I wanted :-(, I hoped that I can avoid the waiting queues etc..
Anyway thanks for help. I didn't know, that I can't use wake_up from RT interrupt handler.
Petr Cervenka
______________________________________________________________
> Od: jan.kiszka@domain.hid
> Komu:  Petr Cervenka <grugh@domain.hid>
> CC:  xenomai@xenomai.org
> Datum: 16.05.2006 13:15
> Předmět: Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative
>
>  Petr Cervenka wrote:
> > Hello,
> > I need to wait in my ioctl handler for an interrrupt. Is it possible to
> use some rtdm_event_timedwait alternative in non-realtime?
> > I'm thinking about using wait_event_interruptible_timeout. Is it a good
> idea or is there a better solution (e.g. rtdm_event compatible))?
> 
> So your interrupt is RT while one of your waiters is non-RT? Then you
> have to forward the RT event (i.e. the IRQ occurrence) via an
> rtdm_nrtsig_t from the IRQ handler to an nrtsig-event handler in non-RT
> context. This handler can then wakeup non-RT waiters.
> 
> This may sound a bit complicated, but you have to remind that there is
> no safe way to schedule a non-RT (Linux) thread directly from the RT
> (Xenomai) domain, because all Linux scheduling services are fully
> preemptible by Xenomai at any time (including the RT IRQ handler).
> 
> Hmm, as you were asking for a non-RT-safe rtdm_event now: the pattern I
> described above might be generalisable to an extended rtdm_event
> supporting both RT and non-RT waiters (non-RT wakers already work). Need
> to think about this...
> 
> Jan
> 
> 
> 

Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

Petr Cervenka wrote:
> I sense, that there could be a problem. the rtdm_nrtsig_handler_t handler have only one argument (rtdm_nrtsig_t *). But I need to get a pointer to the device and/or the event which has happended and needs to be forwarded to tha waiter.

Yes, the nrtsig interface is a bit unhandy in this regard.

Recent restructuring of the Ipipe patch enabled cookie support also for
rtdm_nrtsig_t, but I refrained from extending the signal handler so far
as this would break existing drivers. Well, as the whole rtdm_nrtsig
interface is inline anyway, adding rtdm_nrtsig_init_ex and
rtdm_nrtsig_handler_ex_t might be a cheap option. You could try this
(untested!):

typedef void (*rtdm_nrtsig_handler_ex_t)(rtdm_nrtsig_t nrt_sig,
                                         void *arg);

static inline int rtdm_nrtsig_init_ex(rtdm_nrtsig_t *nrt_sig,
                                      rtdm_nrtsig_handler_ex_t handler,
                                      void *arg)
{
    *nrt_sig = rthal_alloc_virq();

    if (*nrt_sig == 0)
        return -EAGAIN;

    rthal_virtualize_irq(rthal_root_domain, *nrt_sig,
                         (rthal_irq_handler_t)handler, arg, NULL,
                         IPIPE_HANDLE_MASK);
    return 0;
}

Hmm, really simple, I should commit this...

> I hope there is a possibility to search all my devices (usualy one :-)) if the argument belongs to it, and then clear all pending "events" and call wake_up for appropriate wait queues.
> But it's not as simple as I wanted :-(, I hoped that I can avoid the waiting queues etc..
> Anyway thanks for help. I didn't know, that I can't use wake_up from RT interrupt handler.

You may want to wait a bit, I'm currently cooking something as I noticed
that we could also gain some benefit from such "dual-use" rtdm_event.
Our middleware's communication service (RTDM-based) currently requires
RT-receivers, but non-RT is on our which list for quite some time as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]