Bernard Dautrevaux wrote:


-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Philippe Gerum
Envoyé : mardi 1 novembre 2005 18:30
À : Jan Kiszka
Cc : xenomai-core
Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs

        ....

Ok, let's go for those changes this way:

1. The I-pipe series needs to be updated so that an opaque cookie is passed to the handler; since we have a change in the interface, the 1.1 series has 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.


I agree with all that is said in this post; however there is just a smal
problem: some very useful tool for xenomai application debug and tune is
LTT; however the only available Adeos+LTT patch is not an ipipe one, but an
old linux-2.6.9 kernel patch.

At least the LTT support should be available with an ipipe-based Adeos-1.1
patch for 2.6.9 (waiting for LTT to support a more recent kernel), so that
LTT is not lost for xenomai (as it seems to be in fact for RTAI).

LTT has been undergoing a significant refactoring recently, so there has been little incentive to go for a combo Adeos+LTT patch over a moving target, this is the reason why Alex - the LTT support maintainer for Xenomai - has focused on a 2.6.9 kernel featuring the previous LTT architecture, and this was a good decision. Upgrading this combo will be done in the I-pipe 1.1 timeframe over the newest LTT support, for sure, basically to get rid of the oldgen Adeos patches for Xenomai completely.

RTAI had problem maintaining the LTT support because of the lack of a maintainer; we do have one. This said, the best way you could contribute to this is crafting a prototype combo between I-pipe 1.0 and a recent LTT core (i.e. the one that relies on the refactored relayfs stuff), especially if you do consider this support as a critical feature. I guess that Alex would be fine working on this base later.

Bernard


3. Changes in the IRQ layer will be made at nucleus level, which is the most efficient way to provide them.

It should be noted that as part of the build system refactoring, the real-time HAL has become a static portion of the Linux kernel, with its generic part being moved to the nucleus. IOW, the proposed changes will basically end up as redispatching some code inside the nucleus.

--

Philippe.

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






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



--

Philippe.

Reply via email to