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 just a bit sarcastic with
the way to say "it's my fault".


> It's a sign that the design might be
> too complex now

frankly speaking, I don't think it's really complex :)


> Things get worse, at least with XENO_OPT_STATS: Due to the runtime
> statistics collection, we may end up with dangling references to our
> xnintr object even after xnintr_shirq_unlock().
>
> We would actually need some kind of IRQ_INPROGRESS + synchronize_irq()
> at i-pipe level. But we have the problem, in contrast to the kernel,
> that we reschedule from inside the handler (more precisely: at nucleus
> level), thus synchronize_irq() would not just wait on some simple
> handler to exit...

Yeah.. we had already conversations on this topic (I think with
Philippe) and, if I recall right, that 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

Reply via email to