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 Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core