[Xenomai-help] XenoEmbeddedPPC Help

[Xenomai-help] XenoEmbeddedPPC Help

[smannori]

Wolfgang:

thanks. I apreciate your indication and I understand the meaning of the
personal mail.

Simone Mannori

[Xenomai-help] Replacement for rt_save_flags_and_cli

[Ignacio García Pérez]

Hi,

Porting app from RTAI. Just another newbie question. Is there a
substitute for rt_save_flags_and_cli / rt_restore_flags ?.

Thanks.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Philippe Gerum]

Ignacio García Pérez wrote:
> Hi,
> 
> Porting app from RTAI. Just another newbie question. Is there a
> substitute for rt_save_flags_and_cli / rt_restore_flags ?.

See include/nucleus/asm-generic/hal.h:

#define rthal_local_irq_save(x)	
#define rthal_local_irq_restore(x)

> Thanks.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Ignacio García Pérez]

Philippe Gerum wrote:

> Ignacio García Pérez wrote:
>
>> Hi,
>>
>> Porting app from RTAI. Just another newbie question. Is there a
>> substitute for rt_save_flags_and_cli / rt_restore_flags ?.
>
>
> See include/nucleus/asm-generic/hal.h:
>
> #define rthal_local_irq_save(x)   
> #define rthal_local_irq_restore(x)

Thanks. I just found the following functions in
include/nucleus/asm-generic/system.h

xnlock_get_irqsave
xnlock_put_irqrestore
xnlock_clear_irqoff
xnlock_clear_irqon

They're just #defines to the rthal_ functions.

Should I use rthal_* or xnlock_* ?

By the way, so far I'm uttery in love with the clean, consistent API of
the native skin.

Nacho.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Jan Kiszka]

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

Ignacio García Pérez wrote:
> Philippe Gerum wrote:
> 
> 
>>Ignacio García Pérez wrote:
>>
>>
>>>Hi,
>>>
>>>Porting app from RTAI. Just another newbie question. Is there a
>>>substitute for rt_save_flags_and_cli / rt_restore_flags ?.
>>
>>
>>See include/nucleus/asm-generic/hal.h:
>>
>>#define rthal_local_irq_save(x)   
>>#define rthal_local_irq_restore(x)
> 
> 
> Thanks. I just found the following functions in
> include/nucleus/asm-generic/system.h
> 
> xnlock_get_irqsave
> xnlock_put_irqrestore
> xnlock_clear_irqoff
> xnlock_clear_irqon
> 
> They're just #defines to the rthal_ functions.
> 
> Should I use rthal_* or xnlock_* ?

I would suggest xnlock_, because this is the higher abstraction layer
(the nucleus on top of the hal).

But: both primitives are rather low-level. Do you really need that
"hard" locks? What are you synchronising this way, IRQ handlers with
tasks, tasks with other tasks?

> 
> By the way, so far I'm uttery in love with the clean, consistent API of
> the native skin.

Would you like to forward this statement to a specific mailing list of a
formely related project? ;) (only kidding, just had to smile)

Jan


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

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Philippe Gerum]

Ignacio García Pérez wrote:
> Philippe Gerum wrote:
> 
> 
>>Ignacio García Pérez wrote:
>>
>>
>>>Hi,
>>>
>>>Porting app from RTAI. Just another newbie question. Is there a
>>>substitute for rt_save_flags_and_cli / rt_restore_flags ?.
>>
>>
>>See include/nucleus/asm-generic/hal.h:
>>
>>#define rthal_local_irq_save(x)   
>>#define rthal_local_irq_restore(x)
> 
> 
> Thanks. I just found the following functions in
> include/nucleus/asm-generic/system.h
> 
> xnlock_get_irqsave
> xnlock_put_irqrestore
> xnlock_clear_irqoff
> xnlock_clear_irqon
> 
> They're just #defines to the rthal_ functions.
> 
> Should I use rthal_* or xnlock_* ?

xnlock is there for SMP support if needed. It's the equivalent of Linux's 
spinlocks, but usable in any context (high priority Xenomai domain or Linux). 
The defines to rthal_* routines are fallbacks for UP configurations.

> 
> By the way, so far I'm uttery in love with the clean, consistent API of
> the native skin.
> 

Well, in its very early days, the RTAI/fusion effort was codenamed "dynamite", 
notably wrt the API refactoring issue. Good to see that it shows.

> Nacho.
> 
> 
> 
> 
> 


-- 

Philippe.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Ignacio García Pérez]

>>Thanks. I just found the following functions in
>>include/nucleus/asm-generic/system.h
>>
>>xnlock_get_irqsave
>>xnlock_put_irqrestore
>>xnlock_clear_irqoff
>>xnlock_clear_irqon
>>
>>They're just #defines to the rthal_ functions.
>>
>>Should I use rthal_* or xnlock_* ?
>>    
>>
>
>I would suggest xnlock_, because this is the higher abstraction layer
>(the nucleus on top of the hal).
>  
>
That's just what I thought.

>But: both primitives are rather low-level. Do you really need that
>"hard" locks? What are you synchronising this way, IRQ handlers with
>tasks, tasks with other tasks?
>  
>
An IRQ handler with a task.

Yeah, I know I could just use rt_intr_disable on that interrupt object,
but for reasons too long to explain, the it is encapsulated in a piece
of code and I'd rather not allow other code to see it. Probably not a
good design but at this stage of the port, I'd like to get it working
under xenomai with as little modifications as possible.

Another place I've used it sometimes is substituting a mutex for very
short pieces of code such as:

cli()
a = b + c;
sti()

It is usually more efficient that using a mutex, and this may be
important in low-end processors with little horsepower.

>>By the way, so far I'm uttery in love with the clean, consistent API of
>>the native skin.
>>    
>>
>
>Would you like to forward this statement to a specific mailing list of a
>formely related project? ;) (only kidding, just had to smile)
>  
>
Man, you just read my mind :-)

I just have to say it:

1- It is amazing that fusion has progressed from conception to its
actual usable, stable state in such a short time.

2- In general, I appreciate good design and robustness over efficiency
and other issues, but IMHO, for real-time systems it must be the number
one priority, which I'm not sure it was in the "formerly related
project". Too many large changes in too many time.

3- The patent issue may not be a priority in the academic world, but it
definitely is for industrial applications.

Nacho.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Jan Kiszka]

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

Ignacio García Pérez wrote:
>>But: both primitives are rather low-level. Do you really need that
>>"hard" locks? What are you synchronising this way, IRQ handlers with
>>tasks, tasks with other tasks?
>> 
>>
> 
> An IRQ handler with a task.
> 
> Yeah, I know I could just use rt_intr_disable on that interrupt object,
> but for reasons too long to explain, the it is encapsulated in a piece
> of code and I'd rather not allow other code to see it. Probably not a
> good design but at this stage of the port, I'd like to get it working
> under xenomai with as little modifications as possible.
> 
> Another place I've used it sometimes is substituting a mutex for very
> short pieces of code such as:
> 
> cli()
> a = b + c;
> sti()
> 
> It is usually more efficient that using a mutex, and this may be
> important in low-end processors with little horsepower.
> 

Agree. But even when developing for a low-end UP system, it's good style
to use spinlocks (IRQ: xnlock_get, task: xnlock_get_irqsave) for it.
They will cause the same code to be generated on UP, but will continue
to work in case more CPUs pop up someday...

> 
>>>By the way, so far I'm uttery in love with the clean, consistent API of
>>>the native skin.
>>>   
>>>
>>
>>Would you like to forward this statement to a specific mailing list of a
>>formely related project? ;) (only kidding, just had to smile)
>> 
>>
> 
> Man, you just read my mind :-)
> 
> I just have to say it:
> 
> 1- It is amazing that fusion has progressed from conception to its
> actual usable, stable state in such a short time.
> 
> 2- In general, I appreciate good design and robustness over efficiency
> and other issues, but IMHO, for real-time systems it must be the number
> one priority, which I'm not sure it was in the "formerly related
> project". Too many large changes in too many time.
> 
> 3- The patent issue may not be a priority in the academic world, but it
> definitely is for industrial applications.
> 

I generally consider the last topic as a psychological issue: people in
industry feel better when they get farther away from well-known mined
places - although the whole area is full of more or less effective mines
these days. As only few minelayers really try to trigger them but rather
use them more subtle, it's an issue, though.

And - hey! - academic world is not that far away from industry! We also
need money to do research, and the state isn't that rich anymore... ;)

Jan


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

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Philippe Gerum]

Jan Kiszka wrote:
> Ignacio García Pérez wrote:
> 
>>>But: both primitives are rather low-level. Do you really need that
>>>"hard" locks? What are you synchronising this way, IRQ handlers with
>>>tasks, tasks with other tasks?
>>>
>>>
>>
>>An IRQ handler with a task.
>>
>>Yeah, I know I could just use rt_intr_disable on that interrupt object,
>>but for reasons too long to explain, the it is encapsulated in a piece
>>of code and I'd rather not allow other code to see it. Probably not a
>>good design but at this stage of the port, I'd like to get it working
>>under xenomai with as little modifications as possible.
>>
>>Another place I've used it sometimes is substituting a mutex for very
>>short pieces of code such as:
>>
>>cli()
>>a = b + c;
>>sti()
>>
>>It is usually more efficient that using a mutex, and this may be
>>important in low-end processors with little horsepower.
>>
> 
> 
> Agree. But even when developing for a low-end UP system, it's good style
> to use spinlocks (IRQ: xnlock_get, task: xnlock_get_irqsave) for it.
> They will cause the same code to be generated on UP, but will continue
> to work in case more CPUs pop up someday...
> 

I would disagree regarding one situation though: the actual SMP one, when the 
construct is really a matter of local preemption. In the case above, using a 
spinlock would uselessly prevent two CPUs or more from entering the same section 
of code, albeit one only needs to keep interrupt-safe on the local processor in 
order to avoid unwanted preemption. Additionally, the only way to go to sleep 
safely holding the spinlock would be to use the nucleus lock, in which case the 
potential for contention would be even higher.

-- 

Philippe.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Ignacio García Pérez]

Jan Kiszka wrote:

>Ignacio García Pérez wrote:
>  
>
>>>But: both primitives are rather low-level. Do you really need that
>>>"hard" locks? What are you synchronising this way, IRQ handlers with
>>>tasks, tasks with other tasks?
>>>
>>>
>>>      
>>>
>>An IRQ handler with a task.
>>
>>Yeah, I know I could just use rt_intr_disable on that interrupt object,
>>but for reasons too long to explain, the it is encapsulated in a piece
>>of code and I'd rather not allow other code to see it. Probably not a
>>good design but at this stage of the port, I'd like to get it working
>>under xenomai with as little modifications as possible.
>>
>>Another place I've used it sometimes is substituting a mutex for very
>>short pieces of code such as:
>>
>>cli()
>>a = b + c;
>>sti()
>>
>>It is usually more efficient that using a mutex, and this may be
>>important in low-end processors with little horsepower.
>>
>>    
>>
>
>Agree. But even when developing for a low-end UP system, it's good style
>to use spinlocks (IRQ: xnlock_get, task: xnlock_get_irqsave) for it.
>They will cause the same code to be generated on UP, but will continue
>to work in case more CPUs pop up someday...
>  
>
Yup. Thank you for the tip. I have never worked with MP and never though
of that problem.

>>Man, you just read my mind :-)
>>
>>I just have to say it:
>>
>>1- It is amazing that fusion has progressed from conception to its
>>actual usable, stable state in such a short time.
>>
>>2- In general, I appreciate good design and robustness over efficiency
>>and other issues, but IMHO, for real-time systems it must be the number
>>one priority, which I'm not sure it was in the "formerly related
>>project". Too many large changes in too many time.
>>
>>3- The patent issue may not be a priority in the academic world, but it
>>definitely is for industrial applications.
>>
>>    
>>
>
>I generally consider the last topic as a psychological issue: people in
>industry feel better when they get farther away from well-known mined
>places - although the whole area is full of more or less effective mines
>these days. As only few minelayers really try to trigger them but rather
>use them more subtle, it's an issue, though.
>  
>
Well, actually I agree. I'm in the industry and I'm not that worried
about the patent issue. What troubled me actually was not the fact that
the "formerly related project" overrided the adeos protection, but
rather the fact that the deceision seemed (to me) somewhat unilateral.

Nacho.

Re: [Xenomai-help] Replacement for rt_save_flags_and_cli

[Philippe Gerum]

Ignacio García Pérez wrote:
> Jan Kiszka wrote:
> 
> 
>>Ignacio García Pérez wrote:
>> 
>>
>>
>>>>But: both primitives are rather low-level. Do you really need that
>>>>"hard" locks? What are you synchronising this way, IRQ handlers with
>>>>tasks, tasks with other tasks?
>>>>
>>>>
>>>>     
>>>>
>>>
>>>An IRQ handler with a task.
>>>
>>>Yeah, I know I could just use rt_intr_disable on that interrupt object,
>>>but for reasons too long to explain, the it is encapsulated in a piece
>>>of code and I'd rather not allow other code to see it. Probably not a
>>>good design but at this stage of the port, I'd like to get it working
>>>under xenomai with as little modifications as possible.
>>>
>>>Another place I've used it sometimes is substituting a mutex for very
>>>short pieces of code such as:
>>>
>>>cli()
>>>a = b + c;
>>>sti()
>>>
>>>It is usually more efficient that using a mutex, and this may be
>>>important in low-end processors with little horsepower.
>>>
>>>   
>>>
>>
>>Agree. But even when developing for a low-end UP system, it's good style
>>to use spinlocks (IRQ: xnlock_get, task: xnlock_get_irqsave) for it.
>>They will cause the same code to be generated on UP, but will continue
>>to work in case more CPUs pop up someday...
>> 
>>
> 
> Yup. Thank you for the tip. I have never worked with MP and never though
> of that problem.
> 
> 
>>>Man, you just read my mind :-)
>>>
>>>I just have to say it:
>>>
>>>1- It is amazing that fusion has progressed from conception to its
>>>actual usable, stable state in such a short time.
>>>
>>>2- In general, I appreciate good design and robustness over efficiency
>>>and other issues, but IMHO, for real-time systems it must be the number
>>>one priority, which I'm not sure it was in the "formerly related
>>>project". Too many large changes in too many time.
>>>
>>>3- The patent issue may not be a priority in the academic world, but it
>>>definitely is for industrial applications.
>>>
>>>   
>>>
>>
>>I generally consider the last topic as a psychological issue: people in
>>industry feel better when they get farther away from well-known mined
>>places - although the whole area is full of more or less effective mines
>>these days. As only few minelayers really try to trigger them but rather
>>use them more subtle, it's an issue, though.
>> 
>>
> 
> Well, actually I agree. I'm in the industry and I'm not that worried
> about the patent issue. What troubled me actually was not the fact that
> the "formerly related project" overrided the adeos protection, but
> rather the fact that the deceision seemed (to me) somewhat unilateral.
> 

Seemed to me too, believe me.

-- 

Philippe.