Bernard Dautrevaux wrote:
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.
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.
Xenomai-core mailing list
Xenomai-core mailing list