Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum <rpm@xenomai.org>]

Bernard Dautrevaux wrote:
>  
> 
> 
>>-----Message d'origine-----
>>De : xenomai-core-bounces@domain.hid
>>[mailto:xenomai-core-bounces@domain.hid] 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@domain.hid
>>https://mail.gna.org/listinfo/xenomai-core
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.