All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: Petr Cervenka <grugh@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm_event_timedwait hang-up - SOLVED
Date: Tue, 21 Mar 2006 17:29:03 +0100	[thread overview]
Message-ID: <442029CF.8030709@domain.hid> (raw)
In-Reply-To: <442018FE.3020906@domain.hid>

Jan Kiszka wrote:
> Petr Cervenka wrote:
> 
>>The problem was in my calling "RT" task. I forgot to switch the new
>>created task to PRIMARY MODE, because I didn't know it's neccessary.
> 
> 
> As Philippe said, it isn't usually required - with exceptions. Let me
> first sketch the standard situation: You registered a read_rt handler
> with your device, but no read_nrt. If your application now calls
> rt_dev_read (or just read() for the POSIX skin) from the "wrong"
> context, RTDM will detect the missing _nrt handler and trigger an
> automatic switch to primary mode (and vice versa). So, no need for
> manual switching in the standard case.
> 
> But if you had registered handlers for both contexts, RTDM will always
> invoke the one for your current mode.

I wonder if marking the call as "conforming" instead of leaving it to 
the current domain would make such handling more intuitive? RT threads 
would automatically switch to primary before always going to the _rt 
routine, while plain Linux tasks would just go to the _nrt one. Am I 
off-base wrt RTDM's logic here?

  This means your _nrt handler must
> handle this mode correctly! This "sticky" behaviour was invented to
> allow providing services both with and without strict determinism. RT
> handler may allocate required resources from pre-allocated but limited
> pools, NRT handlers are free to use Linux services for this. This is
> used in practice e.g. by the 16550A driver or RTnet.
> 
> It may appear a bit tricky for IOCTL handlers to implement this scheme,
> as the actual service demultiplexing happens inside the handler, and
> there might be some IOCTLs exclusively for RT and some only for NRT. In
> this case, just reject wrong context invocations by returning -ENOSYS.
> RTDM will then re-invoke the service after toggling the context. See the
> IOCTL handling of the timerbench driver as example.
> 
> 
>>I still have same problems with porting the driver, but I think I can
>>handle them myself.
>>Thanks for your help.
>>Petr Cervenka
>>
> 
> 
> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.


  reply	other threads:[~2006-03-21 16:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-20 13:34 [Xenomai-help] rtdm_event_timedwait hang-up Petr Cervenka
2006-03-20 13:59 ` Jan Kiszka
2006-03-20 14:27   ` Philippe Gerum
2006-03-20 14:56     ` Jan Kiszka
2006-03-20 15:27       ` Philippe Gerum
2006-03-20 16:13         ` Jan Kiszka
2006-03-20 16:20 ` Jan Kiszka
2006-03-20 16:54   ` Philippe Gerum
2006-03-20 17:02     ` Jan Kiszka
2006-03-20 17:26       ` Philippe Gerum
2006-03-21  0:48         ` Alexis Berlemont
2006-03-21  2:04           ` Jan Kiszka
2006-03-21  2:04           ` [Xenomai-core] COMEDI over RTDM (was: rtdm_event_timedwait hang-up) Jan Kiszka
2006-03-22  1:24             ` [Xenomai-core] " Alexis Berlemont
2006-03-24 17:31               ` [Xenomai-core] Re: COMEDI over RTDM Jan Kiszka
2006-03-20 18:01   ` [Xenomai-help] rtdm_event_timedwait hang-up Petr Cervenka
2006-03-20 23:02     ` Jan Kiszka
2006-03-20 23:31       ` Jeff Webb
2006-03-21 14:03       ` [Xenomai-help] rtdm_event_timedwait hang-up - SOLVED Petr Cervenka
2006-03-21 14:17         ` Philippe Gerum
2006-03-21 15:17         ` Jan Kiszka
2006-03-21 16:29           ` Philippe Gerum [this message]
2006-03-21 16:56             ` Jan Kiszka
2006-03-21 17:34               ` Philippe Gerum
2006-03-21 18:18                 ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=442029CF.8030709@domain.hid \
    --to=rpm@xenomai.org \
    --cc=grugh@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.