, Philippe
has no objections here).
>
> Jan
>
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 02/07/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Dmitry Adamushko wrote:
> > On 01/07/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> >> Hi all,
> >>
> >> I've just uploaded my rebased patch stack, including specifically the
> >> las
your first patch.
> Uhh, be careful, I burned my fingers with similar things recently as
> well. You have to make sure that all types are resolvable for _all_
> includers of that header. Otherwise, I'm fine with cleanups like this.
> But I think there was once a reason for #define.
ye
Hello Jan,
well, take it with 2 huge grains of salt.. it's even not compile-tested :-)
I don't think I've got it really nicer than your first patch.. the only
additional point is that
'prev = xnstat_get_current()' reference is also tracked as reference accounting
becomes
a part of the xnstat i
e seems to be on top of your
previous one)? I'll try to come up with some solution during this
weekend.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
was one of the reasons. That's
why synchronize_irq() is in the nucleus layer.
>
> Jan
>
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
hile we
> do not care about the non-shared, standard scenario.
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) :-/
> Sigh, the never ending IRQ story...
should be reviewed.
>
>
nished anyway by the "while (intr && intr != end)"
condition.. So sometimes it acts as yet _another_ check to exit the
loop, IOW "while (intr && intr != end)" may be converted to just
"while (intr)".
>
> Jan
>
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
a reported earlier case
with xnintr_edge_shirq_handler().. but your approach does make code
shorter (and likely simpler), right? I don't see any problems it would
possibly cause (maybe I'm missing smth yet :)
--
Best regards,
Dmitry Adamushko
__
Hi,
> I came across Dmitry Adamushko doing the same work,
> may if any pointers you have will help us.
That was my intention and I started to implement some bits.. but
shortly after that you announced an "alsmost-completed" port (as I
recall it was estimated to be released somewh
https://mail.gna.org/listinfo/xenomai-core
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
rs? I guess, no. But that would
definitely have been a good idea.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
:)
Ok, maybe it's just in theory. e.g. lock and unlock for x86 seem to imply a
full memory barrier (and, probably, all the rest systems does the same).
Just look at definitions of mb() and spinlocks() for x86. asm("lock; some
write ops") does the trick in
ier() at the
same time (have to check more thoroughly) anyway.
Any suggestions?
-- Best regards,Dmitry Adamushko
--- xenomai/ksrc/nucleus/intr-old.c 2006-11-12 00:17:56.0 +0100
+++ xenomai/ksrc/nucleus/intr.c 2006-11-12 00:22:15.0 +0100
@@ -135,12 +135,14 @@ static inline void
ftingsome instrumentation point after the rescheduling, that's it.
yes, per-IRQ accounting (as opposed to per-ISR) wouldn't have a background for such objections.
Well, if we conclude that the enhanced scheme provides better
informativeness and everyone benefiits fr
ep, I like repeating myself :) IMHO the simple model, at
least, clearly answeres a question what's behind the numbers while the
complex one makes the answer more complex trying to be fair in one
place and at the same time adding "unfairness" in another place.
--Philippe.-- Best re
On 15/09/06, Philippe Gerum <[EMAIL PROTECTED]> wrote:
On Fri, 2006-09-15 at 00:12 +0200, Dmitry Adamushko wrote:[...]>> And it's not a good idea to get ipipe_catch_event() buzy spinning as> (as I understand) ipipe_dispatch_event() may take, in general, an
> unbounded a
(EVENT_TYPE, arg);
...
}
ipipe_gets_synched()
- lock
- if somewhere_stored->counter != 0
- adds a caller to some wait queue (impl. depends on domain)
- unlock
- gets blocked.
virtual_irq_handler()
- lock
- wakeup_all_blocked for a given EVENT_TYPE and domain
- unlock
-- Best regards,Dmitry Ad
Some more code reading would be required.
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
n the __ipipe_dispatch_event().
0xcd in case of Nils.
[] __ipipe_dispatch_event+0xcd/0xeb
?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 06/09/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:
> -menu "Shared interrupts">> +menuconfig XENO_OPT_SHIRQ
>> + bool "Shared interrupts">>>> config XENO_OPT_SHIRQ_LEVEL>> bool "Leve
depends on XENO_OPT_SHIRQ+ default yhelp
So a user may end up with XENO_OPT_SHIRQ being enabled while both LEVEL
and EDGE are disabled? Maybe it's worth to make LEVEL "y" by default as
it's likely to be a required option?
-- Best regards,Dmitry Adamushko
___
head. Yep, you are right (heh...
you are asking who had doubts? :)
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
uot;selectable"
only when XENO_OPT_SHIRQ_EDGE is on or (2) select XENO_OPT_SHIRQ_EDGE
automatically when the driver has been choosen.
Jan-- Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
T_SHIRQ_LEVEL && !CONFIG_XENO_OPT_SHIRQ_EDGE */
return xnarch_hook_irq(intr->irq, &xnintr_irq_handler, intr->iack,
intr);
#endif /* CONFIG_XENO_OPT_SHIRQ_LEVEL || CONFIG_XENO_OPT_SHIRQ_EDGE */
}
?
-- Best regards,Dmitry Adamushko
__
Looks like our patch review failed... :-/
I failed and "got my face in the soup" (as it's said in my country).
But as I can see Philippe's corrections fix only compilation issues,
i.e. (2). (1) still remains unclear. Can't see any explanation so far,
if only xeno_16550A
ject_changed(handle) should be called when the object's
internal state changes... just the very first idea and maybe not the
best one.
--Philippe.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
rt;
rev =
nkpod->threadq_rev;
(3)
...
btw, (3) doesn't make any sense. You can be there only when "nkpod->thread_rev == rev".
In fact, nkpod also can be NULL in (2) if xnpod_shutdown() was called
(skin was unloaded) before (1).
---> sync with memory
or
[ write-back ] ---> delay synching
?
It seems to be correct indeed. IOW, any write op. involves cache line
fetching (from L2 cache or main memory) if it's not in the L1.
--
Best regards,Dmitry Adamushko
___
Xenom
vs. e.g. our_strcpy() should be likely longer so we may win something indeed.
Any thoughts?
--Philippe.-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 30/08/06, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
(cache line == 128 bits) let's say cacheline[4]
int a = 1; // e.g. &a == 0xabcd0004
this part of memory is currently not in the cache. So :
1) [0xabcd, 0xabcd0010] == 128 bits is loaded from memory into cacheline.
]
int a = 1; // e.g. &a == 0xabcd0004
this part of memory is currently not in the cache. So :
1) [0xabcd, 0xabcd0010] == 128 bits is loaded from memory into cacheline.
2) then 1 is loaded into cacheline[1]
3) [ write-through ] ---> sync with m
nditional jumps is more pipeline-friendly.
And a compiler is not (always) "smart" (should it be though?) enough to make the following transformation :
unlikely(a) && unlikely(b) => unlikely(a + b)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 29/08/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:I think the additional costs of maintaining an error counter are almostnegligible. The test is in the unlikely path, and the first conditionalready keeps us away from touching the counter.
But it's updated (un
-ENOATTACHMENT (also a common issue...)
now fixed.
Jan-- Best regards,Dmitry Adamushko
diff -upr xenomai-SVN/include/nucleus/intr.h xenomai/include/nucleus/intr.h
--- xenomai-SVN/include/nucleus/intr.h 2006-07-20 11:09:01.0 +0200
+++ xenomai/include/nucleus/intr.h 2006-08-29 21:20
s |= XN_ISR_NOENABLE;
+ }
I tend to think this would be nicer?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
person who has writen this buggy code was me :o) Well, it's probably a time for some refactoring.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 22/08/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:.>> diff -urp xenomai-SVN/include/nucleus/intr.h xenomai-a/include/nucleus/intr.h> --- xenomai-SVN/include/nucleus/intr.h2006-07-20 11:09:01.0 +0200> +++ xenomai-a/include/nucleus/intr.h
a branch with rthal_irq_cookie() (but as I recall it worked when it was implemented) as I don't have any
driver at hand to be loaded.
TIA,
Thanks,Jan-- Best regards,Dmitry Adamushko
diff -urp xenomai-SVN/include/nucleus/intr.h xenomai-a/include/nucleus/intr.h
--- xenomai-SVN/include/nucleu
: your second mail is still pending as well as some related code
reading as, honestly, I don't have a clue at the moment. should be
handled asap :]
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 21/08/06, Philippe Gerum <[EMAIL PROTECTED]
> wrote:
On Mon, 2006-08-21 at 10:36 +0200, Dmitry Adamushko wrote:> [ timer.c.patch] xnticks_t is unsigned while (as I understand)> "xntlholder_date(&timer->plink) - nkpod->jiffies" can be negative.
ok, I somehow miss
On Mon, 2006-08-21 at 12:47 +0200, Dmitry Adamushko wrote:
>> what about pipe-related change (I mean timeslice updating in
> xnpipe_recv()) ?>It's basically useless, since xnsynch_sleep_on() handles the resourcestealing case internally, and the loop in xnpipe_recv is fake actually
what about pipe-related change (I mean timeslice updating in xnpipe_recv()) ?-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
n theory, 1 may cause an (even) infinite loop in
xnpipe_recv() as I don't like a check for "timeout > 1" to be placed
there. It's something that should be decided at the timer layer - I
mean, whether it's too late to sleep or not.
hope, I haven't overlooked anything
I don't like a check for "timeout > 1" to be placed
there. It's something that should be decided at the timer layer - I
mean, whether it's too late to sleep or not.
hope, I haven't overlooked anything this time :o)
-- Best regards,Dmitry Adamushko
--- pipe-SVN.c 2006
uot;WITHOUT ANY WARRANTY..." but indeed :) apply this patch so far if you really need synch. message passing mechanism.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
This value is rounded up to a page size.
rt_pipe_create()
{
...
if (poolsize < 2 * PAGE_SIZE)
poolsize = 2 * PAGE_SIZE;
poolsize = xnheap_rounded_size(poolsize, PAGE_SIZE);
-- Best regards,Dmitry Adamushko
___
Xenomai-core
t;-stealing for FOWNER objects. Sounds
funny? :)
if (testbits(synch->status, XNSYNCH_FOWNER | XNSYNCH_PENDING) == XNSYNCH_FOWNER) {
// the object has been stolen while a thread was waiting to be scheduled on
}
-- Best regards,Dmitry Adamushko
_
iff -u old-patch new-patch to find out this typo :)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ould be ok or maybe I'm completely wrong and see the things which do not exist at all :)
p.s. I cc'ed "xenomai-core" as it may involve further discussions and it's the right place indeed.
-- Best regards,Dmitry Adamushko
diff -urp xenomai-a/include/nucleus/synch.
words. IOW, if I'm right let's my carma to be
updated, if no - weeell you know I'm still leeeaarning but see I can
solve this quadr. math equotion !
err.. hope the majority of people subscribed to this mailing list have got good spam filters :)
Jan--
e so :)
So I don't see any problem here. Sure I don't know all the
implementation details and can be just driven by my own
misunderstanding.
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
like xnthread_task_unblockable/blockable(task) would be also of avail.
Oh, my dear. I should stop hacking patches while talking to colleagues.
Does this one make more sense?
maybe it's better that the other way around? I mean, writting good code and saying nonsense to your collegues... :o>
-- Best r
lock_and_exit;- }-- if (xnpod_unblockable_p()) {+ } else if (xnpod_unblockable_p()) {err = -EPERM;
goto unlock_and_exit;}-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@
sysenter_exit and that's "sysexit".
I tried to find what exactly "sysexit" does and when/why it may fault
but failed so far. e.g. if ecx is wrong (points to non-existent vma).
It's also interesting that 2 tasks get GPF, both returning from some syscall.
Maybe
her thread but it doesn't really matter.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
s" signals.
btw, according to POSIX 1003.1-2003, the write() call is amongst "safe" ones.
http://www.die.net/doc/linux/man/man2/signal.2.html
So write(1, ); heh... not that nice? :)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core
the owner.
So why just not to bail out XNBREAK and continue task2 as it has a
mutex (as shown above) ?
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
" (keeps shadow's xnthread_t *) must be
cleared. Another logic could be applied for the rest, I guess.
p.s. I haven't read you patch yet so all said above is out of current context :)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing
Hello,
this fix prevents possible deadlocks in rt_intr_delete() vs. ISR
handlers that I have mentioned earlier.
--
Best regards,
Dmitry Adamushko
native-intr.c-delete-rework.patch
Description: Binary data
posix-intr.c-delete-rework.patch
Description: Binary data
Changelog-delete
here will be the same problem
as with xnintr_detach() - i.e. xnintr_disable (sync) can't be called
from a locked section as it's actually done in rt_intr_delete() (of
course, if we do really need the atomicy in the later one).
> --
>
> Philippe.
>
--
Best regards,
Dmitry Adamush
_shirq - interface is not complete
and safe without xnintr_shirq_spin() on detaching step and it becomes
somewhat blured with the enforcement like "on SMP systems one should
always call xnintr_synchronize() right after calling xnintr_detach()".
So I'm still thinking how to fix it bette
e.g.
it would be better to run the following code from xnintr_shirq_handler()
...
while (intr)
{
s |= intr->isr(intr) & XN_ISR_BITMASK;
++intr->hits;
intr = intr->next;
}
...
already from the thread context.
--
Best regards,
Dmitry Adamushko
river development but may happilly find himslef in
trouble using the native or posix skin.
I'm finding a way to solve them more gracefully now.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.or
to use cirtical_enter/exit() in xnintr_shirq_*
anymore, the nklock can be used instead.
this would solve one synch. problem in xnintr_* code, though there is
yet another and more complex one I'm banging my head on now :o)
--
Best regards,
Dmitry Adamushko
__
me ago that this is a _must_ now for any arch
to be compatible with adeos-ipipe.
If so, with some minor cleanups (XN_ISR_NOENABLE should be removed all
over the map,
docs fixes, ...) and testing the patch may hopefully find its way into
the codebase.
Any feedback?
TIA,
--
Best regards,
om different domains too. As a result, a given
IRQ line is enabled (at the hw layer) but remains to be "LOCKED" in the domain where .ack
took place.
The same may happen if a rt ISR calls ->enable() and then asks nucleus to propagate an interrupt
down to the Linux domain where .end takes place.
> --
>
>Philippe.
>
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Hello,
I overlooked that the logic of decrementing the interrupt nesting count has been changed recently and
both xnintr_shirq_handler() and xnintr_edge_shirq_handler() behave wrong in this respect.
The attached patch fixes this misbehavior.
-- Best regards,Dmitry Adamushko
intr.c.patch
be used by default, I guess. Or maybe we don't need it at all?
> >
>
> The disable nesting count at Xenomai level is needed to let ISRs act independently
> from each others wrt interrupt masking - or at the very least, to let them think
> they do. This is strictly a Xenomai iss
@ -645,7 +653,7 @@ unlock_and_exit:
return err;
}
-int xnintr_shirq_detach (xnintr_t *intr)
+static int xnintr_shirq_detach (xnintr_t *intr)
{
xnintr_shirq_t *shirq = &xnshirqs[intr->irq];
xnintr_t *e, **p = &shirq->handlers;
@@ -695,6 +703,11 @@ int xnintr_shirq_detach (xnintr_t *intr)
return err;
}
+static void xnintr_synchronize (xnintr_t *intr)
+{
+ xnintr_shirq_spin(&xnshirqs[intr->irq]);
+}
+
int xnintr_mount(void)
{
int i;
---
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 01/03/06, Philippe Gerum <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:>> On 01/03/06, *Philippe Gerum* <[EMAIL PROTECTED] [EMAIL PROTECTED]>>> wrote:>
>> The other option I've described for> dealing with overruns in rt_task_wait_period wo
;overrun)) as they normally
run in the (more or less) studied and tweaked environment.
Ok, some "paranoid" programmers would think differently even then
but there is always the (*) way :o)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
gards,Dmitry Adamushko
arm-hal.c.patch
Description: Binary data
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ret = RTDM_IRQ_HANDLED; } if (ctx->in_nwait > 0) {
My fault, sorry. I should have fixed that but overlooked again.
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 28/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> ...> Ok, are there any objections as to the current patch? If no, please apply.>Oops, I found a minor problem:make[2]: Entering directory `/usr/src/xenomai/build/doc/doxygen'
doxygen/usr/src/xenom
ation for PPC is not yet clear at the moment. That's it...
Ok, are there any objections as to the current patch? If no, please apply.
CHANGELOG.patch is here https://mail.gna.org/public/xenomai-core/2006-02/msg00154.html
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description
st represent an .end substitution for each sub-arch supported.
> IOW, the patch, the way you discussed it recently, is ok for me too.
This said, I'm going to publish the shirq patch (after finalizing ISR return bits,
where I still have some doubts) without
le (e.g. enable_irq() -> handler->enable() in bottom half)
Could it be such an arch feature? It looks to me that it's logically wrong anyway.
Heh... if one is still reading these lines, thanks for your time indeed! :o)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
the IRQ line enabling until later, it will affect
all others ISR => all interrupts are temporary not accepted on this line.
This scenario is possible under Linux, but should be used with even more
care in real-time system. At least, this way HANDLED_NOENABLE case works
and doesn't lead to lost interrupts on some archs.
Moreover, it avoids the need for ENABLE flag even in non-shared interrupt case.
-- Best regards,Dmitry Adamushko
the IRQ line enabling until later, it will affect
all others ISR => all interrupts are temporary not accepted on this line.
This scenario is possible under Linux, but should be used with even more
care in real-time system. At least, this way HANDLED_NOENABLE
ir side-effects and pitfalls precisely";
on the other hand,
I'd say that I'm almost ready to vote against merging the irq sharing code at all as it looks to be a rather partial solution.
-- Best regards,Dmitry Adamushko
On 21/02/06, Anders Blomdell <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:>> N.B. Amongst other things, some thoughts about CHAINED with shared> interrupts.>>> On 20/02/06, *Anders Blomdell* <
[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>>>>
On 21/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> N.B. Amongst other things, some thoughts about CHAINED with shared> interrupts.>>> On 20/02/06, Anders Blomdell <
[EMAIL PROTECTED]> wrote:>>>>> A number of questions arise
ir side-effects and pitfalls precisely";
on the other hand,
I'd say that I'm almost ready to vote against merging the irq sharing code at all as it looks to be a rather partial solution.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 21/02/06, Anders Blomdell <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:>> N.B. Amongst other things, some thoughts about CHAINED with shared> interrupts.>>> On 20/02/06, *Anders Blomdell* <
[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>>>>
On 21/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> N.B. Amongst other things, some thoughts about CHAINED with shared> interrupts.>>> On 20/02/06, Anders Blomdell <
[EMAIL PROTECTED]> wrote:>>>>> A number of questions arise
OPAGATE 3
Yep, I'd agree with you. Moreover, PROPAGATE should not be used for shared interrupts.
-- Best regards,Dmitry Adamushko
OPAGATE 3
Yep, I'd agree with you. Moreover, PROPAGATE should not be used for shared interrupts.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
it.
So one may consider HANDLED == 1 and NOINT == 0 as really scalar values
and
NOENABLE and PROPAGATE as additional bits (used only if needed).
-- Best regards,Dmitry Adamushko
it.
So one may consider HANDLED == 1 and NOINT == 0 as really scalar values
and
NOENABLE and PROPAGATE as additional bits (used only if needed).
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/l
On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:>> Dmitry Adamushko wrote:>>> On 16/02/06, Jan Kiszka <
[EMAIL PROTECTED]> wrote:>>>>>> Hmm, I still find XN_ISR_
On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:>> Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this>> before merging (
i.e. make XN_ISR_HANDLED non-zero)?>>>
On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:>> Dmitry Adamushko wrote:>>> On 16/02/06, Jan Kiszka <
[EMAIL PROTECTED]> wrote:>>>>>> Hmm, I still find XN_ISR_
EN] member (as it was before
actually).
If it's ok, then I'll send um... yet another final patch that addresses both issues :)
Jan-- Best regards,Dmitry Adamushko
On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> On 16/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:>> Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this>> before merging (
i.e. make XN_ISR_HANDLED non-zero)?>>>
EN] member (as it was before
actually).
If it's ok, then I'll send um... yet another final patch that addresses both issues :)
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
nterrupts;
CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones.
I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge.
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description: Binary data
shirq-KConfig.patch
Description: Binary data
ChangeLog.patch
Description: Binary data
nterrupts;
CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones.
I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge.
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description: Binary data
shirq-KConfig.patch
Description: Binary data
ChangeLog.patch
Descriptio
On 13/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:> On 11/02/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:>> Dmitry Adamushko wrote:>>> And as an additional option,>>> it could be interesting to print out to the log if not all "cou
1 - 100 of 225 matches
Mail list logo
