Philippe Gerum wrote:
On Wed, 2007-06-20 at 19:08 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-06-18 at 10:27 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
...
The answer I found is to synchronise all time bases as good as possible.
That means if one base changes its wall
On 20/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
xnintr_attach/detach()).. your approach does increase a worst case
length of the lock(intrlock) -- unlock(intrlock) section... but
that's unlikely to be critical.
I think, the patch I sent before addresses a reported earlier case
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2007-06-20 at 19:08 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-06-18 at 10:27 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
...
The answer I found is to synchronise all time bases as
On Thu, 2007-06-21 at 11:06 +0200, Philippe Gerum wrote:
users is too vague a term. If we are talking about application
developers, they should feel deep in their guts that using something
within the xnarch layer is terminally wrong, so the point is moot
anyway.
Who I'm talking about are
Dmitry Adamushko wrote:
On 20/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
xnintr_attach/detach()).. your approach does increase a worst case
length of the lock(intrlock) -- unlock(intrlock) section... but
that's unlikely to be critical.
I think, the patch I sent before addresses
Philippe Gerum wrote:
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
If you think of it, decoupling only requires to keep a constant epoch
(at least one the nucleus does not update) somewhere within the timebase
struct,
the user code could wire to some value when
On Thu, 2007-06-21 at 11:21 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
If you think of it, decoupling only requires to keep a constant epoch
(at least one the nucleus does not update) somewhere within the
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
Unfortunately, that whole thing make me meditate about the whole issue
again. And now I wonder why we make such a fuss about locking for shared
IRQs (where it should be correct with any of the new patches) while we
do not care about
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
can we just switch over to pci_register_driver in order to avoid
deprecated (and soon removed) pci_module_init? Or do we also need some
wrapper for older 2.4 kernels (latest 2.4 is already aligned with 2.6)?
It works with 2.4.25, at least and from my
Dear Gregory,
we haven't started working on Xenomai on the AT91SAM platform, yet.
Actually, we don't even know if we will...
Can you tell me what is the current status of the AT91SAM support in Xenomai ?
I remember that you already sent me a preliminary patch some weeks ago...
Did you make
2007/6/21, Claudio Scordino [EMAIL PROTECTED]:
Dear Gregory,
we haven't started working on Xenomai on the AT91SAM platform, yet.
Actually, we don't even know if we will...
Can you tell me what is the current status of the AT91SAM support in Xenomai ?
I remember that you already sent me
Dmitry Adamushko wrote:
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
Unfortunately, that whole thing make me meditate about the whole issue
again. And now I wonder why we make such a fuss about locking for shared
IRQs (where it should be correct with any of the new patches) while
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ .. ]
surprise-surprise.. sure, one way or another it must be fixed. heh..
too many bugs (and I don't even want to say who's responsible) :-/
I wouldn't accept all the responsibility if I were you.
I have no problems in this respect. I was
Dmitry Adamushko wrote:
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ .. ]
surprise-surprise.. sure, one way or another it must be fixed. heh..
too many bugs (and I don't even want to say who's responsible) :-/
I wouldn't accept all the responsibility if I were you.
I have no
On Thu, 2007-06-21 at 13:20 +0200, Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
can we just switch over to pci_register_driver in order to avoid
deprecated (and soon removed) pci_module_init? Or do we also need some
wrapper for older 2.4 kernels (latest 2.4 is
On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Well, and I wonder what this xnarch_memory_barrier() at each handler
entry is for. Seems to be there for ages, don't see why right now.
AFAICT, this probably dates back to Xenomai 1.x, when we used to have a
threaded
Philippe Gerum wrote:
On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Well, and I wonder what this xnarch_memory_barrier() at each handler
entry is for. Seems to be there for ages, don't see why right now.
AFAICT, this probably dates back to Xenomai 1.x, when we used
Philippe Gerum wrote:
On Thu, 2007-06-21 at 11:21 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
If you think of it, decoupling only requires to keep a constant epoch
(at least one the nucleus does not
18 matches
Mail list logo
