Re: [Xenomai-core] RFC: 2.5 todo list.

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

Philippe Gerum wrote:
> On Fri, 2009-10-02 at 21:25 +0200, Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> On Tue, 2009-09-29 at 19:31 +0200, Gilles Chanteperdrix wrote:
>>>>> Hi guys,
>>>>>
>>>>> full of energy after this tremendous first XUM,
>>>> Agreed, thanks to the DENX folks for having thought of it in the first
>>>> place, and organized it nicely.
>>>>
>>>>>  I would like to start a
>>>>> discussion about what people would like to see in the 2.5 branch.
>>>>>
>>>> Jan has described the situation quite accurately already, regarding the
>>>> trade-off between getting everything we want into 2.5 so that no 2.6 is
>>>> required, and releasing the too long-awaited 2.5 asap.
>>>>
>>>> As you mentioned already, the key issue is ABI stability.
>>>> Any change we want before 3.0 that breaks the ABI should preferably go
>>>> to 2.5, so that we don't end up maintaining 2.5.x, 2.6.x and 3.x. At any
>>>> rate, we could not afford the latter anyway. This is a different matter
>>>> than API issues; we already allowed API extensions during a stable
>>>> cycle, provided they do not break existing application code (except in
>>>> emergency cases), so I see no problem in pushing a few more services to
>>>> 2.5.1 and beyond, provided that condition is met.
>>>>
>>>>> Here is a first list, please feel free to criticize it:
>>>>> - signals in primary domain (something that we almost forgot)
>>>> Yes, this one must be in. At least, we should break the ABI one more
>>>> time for this before releasing 2.5.0. This item has priority #1 for
>>>> me, since providing that infrastructure will enable a series of
>>>> additional services to be implemented properly. In fact, this is more a
>>>> matter of allowing nucleus callouts to user-space than anything else;
>>>> POSIX RT signals in full primary mode being an application of them.
>>> Ok. So, if we add the core skin fdtable, this leaves us with two items:
>>> - signals in primary domain
>> Sorry, I neither see the need nor feel comfortable about the impact /
>> side effects of such an extension.
>>
> 
> This extension is mandatory to allow callouts from the nucleus to a
> user-space application without forcing the latter to leave primary mode.
> This is direly needed when implementing some legacy RTOS services, and
> currently only available from kernel to kernel. We need this 1) to
> implement POSIX RT signals (a long term maintenance release like 2.5
> must have those), 2) implement missing services from existing skins
> (VxWorks comes to mind), 3) provide an upgrade path from 2.5.x to 3.x,
> for people who will have to move their apps to userland in v3, and as
> such should be able to anticipate that move with 2.5.
> 
> The impact is minimal, we have discussed the general idea in a previous
> thread actually. This is typically something that is implemented between
> the shadow support code and the generic syscall code, this does not have
> to leak anywhere else.

I understand the need for it now, but I will likely not share your
optimism regarding the orthogonality of this change until I saw the
code. My worries about when we will see 2.5.0 are increasing again.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]