[Xenomai-help] Sychronize between Linux and Xenomai domain

[Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Hi,

Xenomai provides synchronize objects like semaphore and mutex and related
APIs, e.g: rt_sem_p(), rt_sem_v().
I think they can only synchonze between Xenomai tasks (e.g, tasks created
with rt_task_create()).

Is there any way to synchonize between a "normal" Linux task and a Xenomai
task?
Is there way to synchronize between Linux and Xenomai domain in Kernel
space? (e.g, a Linux driver and a Xenomai driver)?

Thanks,

-Yi

[-- Attachment #2: Type: text/html, Size: 479 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Hi,
> 
> Xenomai provides synchronize objects like semaphore and mutex and related
> APIs, e.g: rt_sem_p(), rt_sem_v().
> I think they can only synchonze between Xenomai tasks (e.g, tasks created
> with rt_task_create()).
> 
> Is there any way to synchonize between a "normal" Linux task and a Xenomai
> task?

Either by simply calling a standard sync-mechanism from the RT task so
that it switches over to secondary mode, or by mapping the Linux task to
a Xenomai task as well. The latter is simple too, and you can even leave
its Linux scheduling policy at SCHED_OTHER with latest Xenomai (upcoming
2.2).

> Is there way to synchronize between Linux and Xenomai domain in Kernel
> space? (e.g, a Linux driver and a Xenomai driver)?

Depends on what you have to protect. The easiest way for short code
passages are still spinlocks with hard IRQ protection (under RTDM:
rtdm_lock_xxx). If it's a more complex scenario, please describe it.
There are several patterns available that may fit. They reach from
polling in the non-RT context over virtual IRQs to Linux
(rtdm_nrtsig_xxx) up to RT helper tasks.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Thanks Jan.

You mentioned:
"Depends on what you have to protect. The easiest way for short code
passages are still spinlocks with hard IRQ protection (under RTDM:
rtdm_lock_xxx). "

I read the code of rtdm_lock_xxx and find it mapped to spin_lock. If I
understand correctly,

a RTDM driver using:
rtdm_lock_get(&my_lock);

a normal linux driver using
spin_lock(&my_lock);

Can be used to protect some shared data structure between RTDM real-time
driver in Xenomai Domain
and a normal Linux driver, right?

I just started to write a RTDM driver, and I am not sure what existing linux
kernel services
I can use in the RTDM driver, e.g, wait queue, semaphores, request_dma(),
free_dma(), etc.
I have concern that the RTDM driver may not synchronize with linux kernel,
since it will
preempt Linux kernel whenever the HW interrupt is not masked.
Is there any guideline there?

Thanks for your advices.

-Yi



On 7/10/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > Hi,
> >
> > Xenomai provides synchronize objects like semaphore and mutex and
> related
> > APIs, e.g: rt_sem_p(), rt_sem_v().
> > I think they can only synchonze between Xenomai tasks (e.g, tasks
> created
> > with rt_task_create()).
> >
> > Is there any way to synchonize between a "normal" Linux task and a
> Xenomai
> > task?
>
> Either by simply calling a standard sync-mechanism from the RT task so
> that it switches over to secondary mode, or by mapping the Linux task to
> a Xenomai task as well. The latter is simple too, and you can even leave
> its Linux scheduling policy at SCHED_OTHER with latest Xenomai (upcoming
> 2.2).
>
> > Is there way to synchronize between Linux and Xenomai domain in Kernel
> > space? (e.g, a Linux driver and a Xenomai driver)?
>
> Depends on what you have to protect. The easiest way for short code
> passages are still spinlocks with hard IRQ protection (under RTDM:
> rtdm_lock_xxx). If it's a more complex scenario, please describe it.
> There are several patterns available that may fit. They reach from
> polling in the non-RT context over virtual IRQs to Linux
> (rtdm_nrtsig_xxx) up to RT helper tasks.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2619 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Thanks Jan.
> 
> You mentioned:
> "Depends on what you have to protect. The easiest way for short code
> passages are still spinlocks with hard IRQ protection (under RTDM:
> rtdm_lock_xxx). "
> 
> I read the code of rtdm_lock_xxx and find it mapped to spin_lock. If I
> understand correctly,
> 
> a RTDM driver using:
> rtdm_lock_get(&my_lock);
> 
> a normal linux driver using
> spin_lock(&my_lock);
> 
> Can be used to protect some shared data structure between RTDM real-time
> driver in Xenomai Domain
> and a normal Linux driver, right?

Yep. See also real-world examples in existing RTDM drivers.

> 
> I just started to write a RTDM driver, and I am not sure what existing
> linux
> kernel services
> I can use in the RTDM driver, e.g, wait queue, semaphores, request_dma(),
> free_dma(), etc.
> I have concern that the RTDM driver may not synchronize with linux kernel,
> since it will
> preempt Linux kernel whenever the HW interrupt is not masked.
> Is there any guideline there?

Keep in mind that Linux may have been preempted AT ANY POINT when your
driver executes some code in hard real-time mode. Therefore, calling
almost all Linux services from RT context must be considered unsafe
(unfortunately, it often works fine in practice, just fails/crashes
"magically" from time to time).

But it's usually not required to do so as most of Linux interaction can
be performed during init/cleanup. Just register your open/socket and
close handler as "_nrt" so that they are only executed in pure Linux or
secondary mode, and you can run whatever Linux service you like.

If you encounter any Linux service that you have to call for your driver
from IRQ or RT context, please report.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

I searched the web and find these RTDM sample drivers (Thanks for the
contributors):

In Xenomai src tree: ksrc/drivers/16550A/16550A.c
http://www.captain.at/xenomai-real-time-driver-example.php
http://www.rts.uni-hannover.de/rtnet/lxr/source/examples/xenomai/
http://www.captain.at/xenomai-serial-port-example.php

Just wondering are there more samples?

Thanks,

-Yi

On 7/10/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > Thanks Jan.
> >
> > You mentioned:
> > "Depends on what you have to protect. The easiest way for short code
> > passages are still spinlocks with hard IRQ protection (under RTDM:
> > rtdm_lock_xxx). "
> >
> > I read the code of rtdm_lock_xxx and find it mapped to spin_lock. If I
> > understand correctly,
> >
> > a RTDM driver using:
> > rtdm_lock_get(&my_lock);
> >
> > a normal linux driver using
> > spin_lock(&my_lock);
> >
> > Can be used to protect some shared data structure between RTDM real-time
> > driver in Xenomai Domain
> > and a normal Linux driver, right?
>
> Yep. See also real-world examples in existing RTDM drivers.
>
> >
> > I just started to write a RTDM driver, and I am not sure what existing
> > linux
> > kernel services
> > I can use in the RTDM driver, e.g, wait queue, semaphores,
> request_dma(),
> > free_dma(), etc.
> > I have concern that the RTDM driver may not synchronize with linux
> kernel,
> > since it will
> > preempt Linux kernel whenever the HW interrupt is not masked.
> > Is there any guideline there?
>
> Keep in mind that Linux may have been preempted AT ANY POINT when your
> driver executes some code in hard real-time mode. Therefore, calling
> almost all Linux services from RT context must be considered unsafe
> (unfortunately, it often works fine in practice, just fails/crashes
> "magically" from time to time).
>
> But it's usually not required to do so as most of Linux interaction can
> be performed during init/cleanup. Just register your open/socket and
> close handler as "_nrt" so that they are only executed in pure Linux or
> secondary mode, and you can run whatever Linux service you like.
>
> If you encounter any Linux service that you have to call for your driver
> from IRQ or RT context, please report.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2963 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> I searched the web and find these RTDM sample drivers (Thanks for the
> contributors):
> 
> In Xenomai src tree: ksrc/drivers/16550A/16550A.c

Also check the drivers/testing in recent Xenomai.

> http://www.captain.at/xenomai-real-time-driver-example.php
> http://www.rts.uni-hannover.de/rtnet/lxr/source/examples/xenomai/
> http://www.captain.at/xenomai-serial-port-example.php

The last two are usage examples, not drivers. But RTnet is indeed
another, more complex example, see these parts:

http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c
http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/ipv4
http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_dev.c

> 
> Just wondering are there more samples?

http://svn.berlios.de/viewcvs/rack/trunk/rack/main/tims/driver
http://www.rts.uni-hannover.de/rtaddon
http://developer.berlios.de/projects/usb4rt
http://developer.berlios.de/projects/rtfirewire (only as API user, not
    as RTDM device provider)

And a full CAN stack is on the way, may show up on the list this week.
Hope I'm not forgetting anything right now.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Hi Jan,

Sometimes there is situation to  protect a  Non-real time task in kernel
space NOT to be interrupted by Xenomai task.
Is disabling HW interrupt the only way? Can I stall Xenomai Domain from
handling interrupt while let the Linux domain
handle interrupt normally?

Thanks,

-Yi


On 7/10/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > I searched the web and find these RTDM sample drivers (Thanks for the
> > contributors):
> >
> > In Xenomai src tree: ksrc/drivers/16550A/16550A.c
>
> Also check the drivers/testing in recent Xenomai.
>
> > http://www.captain.at/xenomai-real-time-driver-example.php
> > http://www.rts.uni-hannover.de/rtnet/lxr/source/examples/xenomai/
> > http://www.captain.at/xenomai-serial-port-example.php
>
> The last two are usage examples, not drivers. But RTnet is indeed
> another, more complex example, see these parts:
>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/ipv4
>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_dev.c
>
> >
> > Just wondering are there more samples?
>
> http://svn.berlios.de/viewcvs/rack/trunk/rack/main/tims/driver
> http://www.rts.uni-hannover.de/rtaddon
> http://developer.berlios.de/projects/usb4rt
> http://developer.berlios.de/projects/rtfirewire (only as API user, not
>     as RTDM device provider)
>
> And a full CAN stack is on the way, may show up on the list this week.
> Hope I'm not forgetting anything right now.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2708 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Hi Jan,
> 
> Sometimes there is situation to  protect a  Non-real time task in kernel
> space NOT to be interrupted by Xenomai task.
> Is disabling HW interrupt the only way? Can I stall Xenomai Domain from

Think of SMP as well (ok, blackfin is UP so far, right? :)): you need
IRQ lock + some spinlock that is acquired in the IRQ handler(s) as well,
thus you end up with that rtdm_lock_t again.

> handling interrupt while let the Linux domain
> handle interrupt normally?

Stalling (i.e. preventing IRQ delivery) higher prio domains (like
Xenomai) implicitly means stalling all lower prio ones (including
Linux): No, this is not possible. You might prevent rescheduling by
setting the scheduler lock of Xenomai, but this still doesn't protect
from IRQs.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Yes. I am concerned about UP situation. But I am still a little confused.

Do you mean in a "normal Linux driver", I can use

rtdm_lock_get_irqsave() to protect my Linux task from being preempted by
Xenomai task?


The code shows that:
"
#define rtdm_lock_get_irqsave(lock, context)    \
    rthal_spin_lock_irqsave(lock, context).

#define rthal_spin_lock_irqsave(lock,x) \
do {  \
    rthal_local_irq_save(x); \
    rthal_spin_lock(lock); \
} while(0)

#define rthal_local_irq_save(x) ((x) =
!!ipipe_test_and_stall_pipeline_from(&rthal_domain)

[-- Attachment #2: Type: text/html, Size: 692 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Sorry that the email was cut off by Gmail (not sure why).

Continue with last mail:

>From the code, it looks rtdm_lock_get_irqsave() will "stalls" Xenomai domain
and implicitly Linux domain, right?

Yesterday I was thinking if a Linux task  uses spin_lock_irqsave() would
disable HW interrupt. So the Linux task can
be protected from being preempted by Xenomai task. But it turns out that
spin_lock_irqsave() will stalls Linux domain only.

Thank you for the clarification.

-Yi

On 7/11/06, Li Yi (Adam) <liyiadam@domain.hid> wrote:
>
> Yes. I am concerned about UP situation. But I am still a little confused.
>
> Do you mean in a "normal Linux driver", I can use
>
> rtdm_lock_get_irqsave() to protect my Linux task from being preempted by
> Xenomai task?
>
>
> The code shows that:
> "
> #define rtdm_lock_get_irqsave(lock, context)    \
>     rthal_spin_lock_irqsave(lock, context).
>
> #define rthal_spin_lock_irqsave(lock,x) \
> do {  \
>     rthal_local_irq_save(x); \
>     rthal_spin_lock(lock); \
> } while(0)
>
> #define rthal_local_irq_save(x) ((x) =
> !!ipipe_test_and_stall_pipeline_from(&rthal_domain)
>

[-- Attachment #2: Type: text/html, Size: 1565 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Sorry that the email was cut off by Gmail (not sure why).
> 
> Continue with last mail:
> 
> From the code, it looks rtdm_lock_get_irqsave() will "stalls" Xenomai
> domain
> and implicitly Linux domain, right?

Yep.

> 
> Yesterday I was thinking if a Linux task  uses spin_lock_irqsave() would
> disable HW interrupt. So the Linux task can
> be protected from being preempted by Xenomai task. But it turns out that
> spin_lock_irqsave() will stalls Linux domain only.

True.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Jan,

Sorry but could you help to confirm the other question in my last (last)
mail:

"Do you mean in a "normal Linux driver", I can use

rtdm_lock_get_irqsave() to protect my Linux task from being preempted by
Xenomai task? "


Thanks many!

-Yi

On 7/11/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > Sorry that the email was cut off by Gmail (not sure why).
> >
> > Continue with last mail:
> >
> > From the code, it looks rtdm_lock_get_irqsave() will "stalls" Xenomai
> > domain
> > and implicitly Linux domain, right?
>
> Yep.
>
> >
> > Yesterday I was thinking if a Linux task  uses spin_lock_irqsave() would
> > disable HW interrupt. So the Linux task can
> > be protected from being preempted by Xenomai task. But it turns out that
> > spin_lock_irqsave() will stalls Linux domain only.
>
> True.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Jan,
> 
> Sorry but could you help to confirm the other question in my last (last)
> mail:
> 
> "Do you mean in a "normal Linux driver", I can use
> 
> rtdm_lock_get_irqsave() to protect my Linux task from being preempted by
> Xenomai task? "
> 

Do I have to sign somewhere? ;)

Yes, you can, and it's actually done in many existing RTDM drivers -
init/cleanup handlers that need to sync with RT users or IRQs typically
uses this mechanism (see the 16550A driver e.g.). And init/cleanup is
mostly performed from standard Linux context.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Hi Jan,

You mentioned that:

"You might prevent rescheduling by
setting the scheduler lock of Xenomai, but this still doesn't protect
from IRQs."

If I don't want to stop Xenomai domain from receiving interrupt at all,
Just want to block certain Xenomai task.
Is there a specific set of functions/macros which disable/enable specific
real-time event
processing (for instance, real-time task execution).  In this scheme,
the ADEOS scheduler still executes, but now checks whether a real-time
task has been "blocked" for execution.  If it is blocked, the scheduler
does not schedule the task. When the real-time task is "unblocked" by
the Linux ROOT domain, it resumes real-time execution.

Thanks,

-Yi

On 7/11/06, Li Yi (Adam) <liyiadam@domain.hid> wrote:
>
> Jan,
>
> Sorry but could you help to confirm the other question in my last (last)
> mail:
>
>
> "Do you mean in a "normal Linux driver", I can use
>
> rtdm_lock_get_irqsave() to protect my Linux task from being preempted by
> Xenomai task? "
>
>
> Thanks many!
>
> -Yi
>
>
> On 7/11/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >
> > Li Yi (Adam) wrote:
> > > Sorry that the email was cut off by Gmail (not sure why).
> > >
> > > Continue with last mail:
> > >
> > > From the code, it looks rtdm_lock_get_irqsave() will "stalls" Xenomai
> > > domain
> > > and implicitly Linux domain, right?
> >
> > Yep.
> >
> > >
> > > Yesterday I was thinking if a Linux task  uses spin_lock_irqsave()
> > would
> > > disable HW interrupt. So the Linux task can
> > > be protected from being preempted by Xenomai task. But it turns out
> > that
> > > spin_lock_irqsave() will stalls Linux domain only.
> >
> > True.
> >
> > Jan
> >
> >
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 2627 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Hi Jan,
> 
> You mentioned that:
> 
> "You might prevent rescheduling by
> setting the scheduler lock of Xenomai, but this still doesn't protect
> from IRQs."
> 
> If I don't want to stop Xenomai domain from receiving interrupt at all,
> Just want to block certain Xenomai task.

Then take care of this in the IRQ handler: if some task shall not
receive any notification, do not deliver. Or disable the specific IRQ
(rtdm_irq_disable) as long as it is not shared and no other tasks are
waiting for it.

> Is there a specific set of functions/macros which disable/enable specific
> real-time event
> processing (for instance, real-time task execution).  In this scheme,
> the ADEOS scheduler still executes, but now checks whether a real-time

Adeos has no scheduler, it only maintains the IRQ/event pipepline.

> task has been "blocked" for execution.  If it is blocked, the scheduler
> does not schedule the task. When the real-time task is "unblocked" by
> the Linux ROOT domain, it resumes real-time execution.

rt_task_suspend/resume of the native skin may help you. But, of course,
this will not prevent the IRQ handler from being executed. And there are
likely other ways, but this depends on your application design which I
don't know. In any case, nothing RT-specific here.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

Thanks Jan.

If I understand correctly, a normal Linux task (in kernel or user space) may
call rt_task_suspend()/rt_task_resume()
to suspend/resume the execution of a RT task -- Originally I am thinking
only RT tasks can use such APIs - Looks I am wrong here.

Thanks for the clafiication.

-Yi



On 7/12/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > Hi Jan,
> >
> > You mentioned that:
> >
> > "You might prevent rescheduling by
> > setting the scheduler lock of Xenomai, but this still doesn't protect
> > from IRQs."
> >
> > If I don't want to stop Xenomai domain from receiving interrupt at all,
> > Just want to block certain Xenomai task.
>
> Then take care of this in the IRQ handler: if some task shall not
> receive any notification, do not deliver. Or disable the specific IRQ
> (rtdm_irq_disable) as long as it is not shared and no other tasks are
> waiting for it.
>
> > Is there a specific set of functions/macros which disable/enable
> specific
> > real-time event
> > processing (for instance, real-time task execution).  In this scheme,
> > the ADEOS scheduler still executes, but now checks whether a real-time
>
> Adeos has no scheduler, it only maintains the IRQ/event pipepline.
>
> > task has been "blocked" for execution.  If it is blocked, the scheduler
> > does not schedule the task. When the real-time task is "unblocked" by
> > the Linux ROOT domain, it resumes real-time execution.
>
> rt_task_suspend/resume of the native skin may help you. But, of course,
> this will not prevent the IRQ handler from being executed. And there are
> likely other ways, but this depends on your application design which I
> don't know. In any case, nothing RT-specific here.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2185 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> Thanks Jan.
> 
> If I understand correctly, a normal Linux task (in kernel or user space)
> may
> call rt_task_suspend()/rt_task_resume()
> to suspend/resume the execution of a RT task -- Originally I am thinking
> only RT tasks can use such APIs - Looks I am wrong here.

Hmm, in theory it should be no problem to call rt_task_suspend(task)
with task != NULL from arbitrary contexts. But the native skin prevents
this. I must confess I do not know the reason behind this right now. The
point is that you do not need to block for remote-suspending some other
task, thus the caller's context should not matter. Anyone else any idea?

rt_task_resume() in contrast is fine from any context again.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Li Yi (Adam)]

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

But how to handle the situation when, e.g, a normal Linux task( in kernel
space) and a Xenomai task (in kernel space),
they share a global data structure. The Linux task want to block the Xenomai
task for a while when it handles this data structure, while
at the same time HW interrupt is enabled? When the data is ready, Xenomai
task is waken up.


Thanks,

-Yi

On 7/12/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Li Yi (Adam) wrote:
> > Thanks Jan.
> >
> > If I understand correctly, a normal Linux task (in kernel or user space)
> > may
> > call rt_task_suspend()/rt_task_resume()
> > to suspend/resume the execution of a RT task -- Originally I am thinking
> > only RT tasks can use such APIs - Looks I am wrong here.
>
> Hmm, in theory it should be no problem to call rt_task_suspend(task)
> with task != NULL from arbitrary contexts. But the native skin prevents
> this. I must confess I do not know the reason behind this right now. The
> point is that you do not need to block for remote-suspending some other
> task, thus the caller's context should not matter. Anyone else any idea?
>
> rt_task_resume() in contrast is fine from any context again.
>
> Jan
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1529 bytes --]

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Jan Kiszka]

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

Li Yi (Adam) wrote:
> But how to handle the situation when, e.g, a normal Linux task( in kernel
> space) and a Xenomai task (in kernel space),
> they share a global data structure. The Linux task want to block the
> Xenomai
> task for a while when it handles this data structure, while
> at the same time HW interrupt is enabled? When the data is ready, Xenomai
> task is waken up.

Simply turn the Linux task into a Xenomai task (set priority to 0 if the
task has otherwise no RT jobs) and use a mutex. That's far cleaner than
playing with suspend/resume anyway.

Jan


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

Re: [Xenomai-help] Sychronize between Linux and Xenomai domain

[Philippe Gerum]

On Tue, 2006-07-11 at 12:25 +0800, Li Yi (Adam) wrote:
> Hi Jan,
> 
> Sometimes there is situation to  protect a  Non-real time task in
> kernel space NOT to be interrupted by Xenomai task.
> Is disabling HW interrupt the only way?

Or stalling the Xenomai stage in the interrupt pipeline. See
rthal_local_irq_* in asm-generic/hal.h. But at the very least, make sure
that no Linux rescheduling occurs during the critical section; this
includes disabling kernel preemption before stalling the Xenomai domain.

>  Can I stall Xenomai Domain from handling interrupt while let the
> Linux domain 
> handle interrupt normally?

No, this would make no sense. Interrupts are flowing down the Adeos
pipeline by domain priority order.

> 
> Thanks,
> 
> -Yi
> 
> 
> On 7/10/06, Jan Kiszka <jan.kiszka@domain.hid > wrote:
>         Li Yi (Adam) wrote:
>         > I searched the web and find these RTDM sample drivers
>         (Thanks for the 
>         > contributors):
>         >
>         > In Xenomai src tree: ksrc/drivers/16550A/16550A.c
>         
>         Also check the drivers/testing in recent Xenomai.
>         
>         > http://www.captain.at/xenomai-real-time-driver-example.php
>         >
>         http://www.rts.uni-hannover.de/rtnet/lxr/source/examples/xenomai/
>         > http://www.captain.at/xenomai-serial-port-example.php
>         
>         The last two are usage examples, not drivers. But RTnet is
>         indeed
>         another, more complex example, see these parts: 
>         
>         http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c
>         http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/ipv4
>         http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_dev.c
>         
>         >
>         > Just wondering are there more samples?
>         
>         http://svn.berlios.de/viewcvs/rack/trunk/rack/main/tims/driver
>         http://www.rts.uni-hannover.de/rtaddon
>         http://developer.berlios.de/projects/usb4rt
>         http://developer.berlios.de/projects/rtfirewire (only as API
>         user, not
>             as RTDM device provider)
>         
>         And a full CAN stack is on the way, may show up on the list
>         this week.
>         Hope I'm not forgetting anything right now.
>         
>         Jan
>         
>         
>         
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.