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 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) :-/

I wouldn't accept all the responsibility if I were you. We all went
through this code several times. It's a sign that the design might be
too complex now, and I feel like having some share in this.

> 
>> Sigh, the never ending IRQ story...
> 
> should be reviewed.
> 

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...

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to