> >> [...]
> >>the "cookie" remains opaque for the ipipe but when requested by
> >>HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a
> >>chain of ISR handlers.
> > Yep, that's also what I had in mind about potential ipipe changes and
> > their use in the nucleus.
> Ok, let's go for those changes this way:
> 1. The I-pipe series needs to be updated so that an opaque cookie ispassed to
> the handler; since we have a change in the interface, the 1.1 serieshas to be
> started for this purpose.
> 2. In order to let the people running the legacy RTAI/fusion and
> Xenomai 2.0.x
> series a reasonable amount of time to upgrade their patchset, the IRQ layer
> updates (sharing and trampoline suppression) will go to the Xenomai 2.1 dev
> branch. IOW, Xenomai 2.1 will be exclusively based on the I-pipe 1.1 series,
> which also means that Xenomai support for the oldgen Adeos and I-pipe 1.0
> patches will be discontinued after the Xenomai 2.0.x series is closed.
> 3. Changes in the IRQ layer will be made at nucleus level, which is the most
> efficient way to provide them.
Ok, I'd take this task (err.. since I'm not doing anything useful for Xenomai at the moment). Although, I may start not earlier than next week.
Jan, since you have come up with the initial proposol and maybe you need get that new code working asap, it's up to you to handle it on your own :o) Just let me know in that case.
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core