Re: [Xenomai-help] Interrupts lost during sleep / unblock cycles

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> On Nov 30, 2007 5:41 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Gilles Chanteperdrix wrote:
>>> Usually, a Xenomai version is compatible with past I-pipe releases. But
>>> you should expect problems using a new I-pipe release with an older
>>> version of Xenomai.
>>>
>> To be more specific about this: we try really, really, really, awfully
>> and painfully hard to keep recent I-pipe patches compatible with
>> (reasonably) older Xenomai releases. No kidding. You may have noticed
>> that the I-pipe API has been quite stable over time for that particular
>> reason, and when we have to break it, there is most often some built-in
>> compat code.
> 
> Then, I really have a problem with the newer ARM I-pipe patches, the
> ones that no longer shut irqs over the mm switch, because they will
> probably compile with a Xenomai 2.2.x, but will not work properly.
>

Well, this is the purpose of "reasonably older" in the sentence. 2.2.x
is already a bit far. 2.3.x is a more reasonable target, particularly
because a shiny new I-pipe patch without all core fixes that went over
time into an entire major Xenomai milestone + maintenance time would not
bring that much. The mm change you mentioned require core surgery in
Xenomai to be compatible, but this was not an API issue.

I'm not sure such kind of changes could ever be detected sanely in older
code, since they don't affect the external interfaces, but require both
the I-pipe and Xenomai cores to agree on interrupt management. This is a
grey area, but not due to API changes.

> The only way I see to work around this is to make the ARM patch depend
> on a CONFIG_ symbol which would be set by the newer Xenomai.
> 

No, we can't do that. We have to admit that sometimes backward compat is
just not possible, unless we start doing really braindamage things. I'm
doing enough silly mistakes unwillingly without wanting to add more of
them deliberately...

-- 
Philippe.