From: "Ignacio García Pérez" <iggarpe@domain.hid>
To: Jan Kiszka <kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Replacement for rt_save_flags_and_cli
Date: Thu, 20 Oct 2005 18:57:33 +0200 [thread overview]
Message-ID: <4357CC7D.2030907@domain.hid> (raw)
In-Reply-To: <4357C464.5050206@domain.hid>
>>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.
next prev parent reply other threads:[~2005-10-20 16:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-20 7:35 [Xenomai-help] XenoEmbeddedPPC Help smannori
2005-10-20 9:43 ` [Xenomai-help] Replacement for rt_save_flags_and_cli Ignacio García Pérez
2005-10-20 10:21 ` Philippe Gerum
2005-10-20 16:08 ` Ignacio García Pérez
2005-10-20 16:23 ` Jan Kiszka
2005-10-20 16:57 ` Ignacio García Pérez [this message]
2005-10-20 18:18 ` Jan Kiszka
2005-10-20 21:10 ` Philippe Gerum
2005-10-21 7:25 ` Ignacio García Pérez
2005-10-21 9:59 ` Philippe Gerum
2005-10-20 16:25 ` Philippe Gerum
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=4357CC7D.2030907@domain.hid \
--to=iggarpe@domain.hid \
--cc=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.