[Xenomai-core] RFC: 2.5 todo list.

[Xenomai-core] RFC: 2.5 todo list.

[Gilles Chanteperdrix]

Hi guys,

full of energy after this tremendous first XUM, I would like to start a
discussion about what people would like to see in the 2.5 branch.

Here is a first list, please feel free to criticize it:
- signals in primary domain (something that we almost forgot)
- xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)
- statistics of all mapped named heaps in /proc/xenomai/heap
- unwapped access to user-space posix skin methods
- fast semaphores in user-space
- syscall-less select ?

Actually, there are already a lot of things.
So, what do you think?

-- 
					    Gilles.

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

[Peter Soetens]

On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> Hi guys,
>
> full of energy after this tremendous first XUM, I would like to start a
> discussion about what people would like to see in the 2.5 branch.

So if we answer positively, we'll delay the release ? I'd rather get
2.5 out, and develop any new stuff on 2.6. I would also expect that
this list (or part of ) goes to xenomai-help too.

>
> Here is a first list, please feel free to criticize it:
> - signals in primary domain (something that we almost forgot)

I refrain from using signals in my apps. They only cause disaster when
using 3rd party libraries. Only Ctrl-C (quit) and debugger signals are
used, and a switch from primary to secondary is perfectly acceptable
in these two cases.

> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)

This is too core for me.

> - statistics of all mapped named heaps in /proc/xenomai/heap

Don't use heaps since we do all in user space (and I had the
impression that heap was for kernel<->user.)

> - unwapped access to user-space posix skin methods

I wouldn't know why I need this. Do you we link with libpthread
instead of libpthread-rt ?

> - fast semaphores in user-space

I donn't know why I wouldn't need this.

> - syscall-less select ?

Since a syscall is not per-se bad (?) I also don't see what to win here.

>
> Actually, there are already a lot of things.
> So, what do you think?

I'm uttermost concerned with stability and to a lesser extent
performance. I regard every feature change as changing those two
criteria for the worse (unless its a feature that fixes a bug).

The kernel and libc are already a moving targets which influence
Xenomai, so we already have to cope with changes more than we want to.

Peter (non-authorative, non-developer)

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

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Hi guys,
>>
>> full of energy after this tremendous first XUM, I would like to start a
>> discussion about what people would like to see in the 2.5 branch.
> 
> So if we answer positively, we'll delay the release ? I'd rather get
> 2.5 out, and develop any new stuff on 2.6. I would also expect that
> this list (or part of ) goes to xenomai-help too.

The facts are:
- our release cycle is long;
- we want to keep the ABI stable for each branch.
So, anything that we want "soon" and that breaks the ABI should be done
in the 2.5 branch, otherwise will have to wait 2.6.

> 
>> Here is a first list, please feel free to criticize it:
>> - signals in primary domain (something that we almost forgot)
> 
> I refrain from using signals in my apps. They only cause disaster when
> using 3rd party libraries. Only Ctrl-C (quit) and debugger signals are
> used, and a switch from primary to secondary is perfectly acceptable
> in these two cases.

Yes, signals is a bit of a misnomer, what we actually want is for the
kernel to be able to cause the execution of an asynchronous callback in
user-space. For the native skin, it would be for the implementation of
some hooks. For the posix skin, it would be for the implementation of
signasl. The implementation of posix timers is based on signals (except
for SIGEV_THREAD, but who uses SIGEV_THREAD in an rt app...), having
them cause a switch to secondary mode make them unusable for practical
purposes. So, with the current version of Xenomai posix skin, you have
to implement your own timer method, having for instance a thread which
nanosleep()s until the next timer expiry and then executes the callback.

> 
>> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)
> 
> This is too core for me.
> 
>> - statistics of all mapped named heaps in /proc/xenomai/heap
> 
> Don't use heaps since we do all in user space (and I had the
> impression that heap was for kernel<->user.)
> 
>> - unwapped access to user-space posix skin methods
> 
> I wouldn't know why I need this. Do you we link with libpthread
> instead of libpthread-rt ?

Well the wrap thing is a bit cumbersome. And having the calls be named
with exactly the posix name is useful only if you intend to compile
exactly the same code for xenomai and other posix systems. Otherwise,
you could decide to use a little prefix or suffix to each posix skin
service, and avoid the wrapping clumsyness.

> 
>> - fast semaphores in user-space
> 
> I donn't know why I wouldn't need this.
> 
>> - syscall-less select ?
> 
> Since a syscall is not per-se bad (?) I also don't see what to win here.

syscall are expensive (which is why we do syscall-less mutexes for
instance). The idea would be to put the bitfield with the ready file
descriptors in a shared heap, to avoid going for the syscall if fds are
already ready when entering select(). The scenario where we would gain
is on a loaded system, which is exactly when we want to avoid useless
syscalls.

> 
>> Actually, there are already a lot of things.
>> So, what do you think?
> 
> I'm uttermost concerned with stability and to a lesser extent
> performance. I regard every feature change as changing those two
> criteria for the worse (unless its a feature that fixes a bug).

Well... I disagree. Even when fixing bugs we can introduce other bugs.
What matters if you aim for stability and performance is improving the
tests, not avoiding modifications.

-- 
                                          Gilles

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

[Peter Soetens]

On Wed, Sep 30, 2009 at 16:27, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Peter Soetens wrote:
>> On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Hi guys,
>>>
>>> full of energy after this tremendous first XUM, I would like to start a
>>> discussion about what people would like to see in the 2.5 branch.
>>
>> So if we answer positively, we'll delay the release ? I'd rather get
>> 2.5 out, and develop any new stuff on 2.6. I would also expect that
>> this list (or part of ) goes to xenomai-help too.
>
> The facts are:
> - our release cycle is long;
> - we want to keep the ABI stable for each branch.
> So, anything that we want "soon" and that breaks the ABI should be done
> in the 2.5 branch, otherwise will have to wait 2.6.

Ok, but there is stuff in 2.5 I want "soon" too, which you would be delaying.

>
>>
>>> Here is a first list, please feel free to criticize it:
>>> - signals in primary domain (something that we almost forgot)
>>
>> I refrain from using signals in my apps. They only cause disaster when
>> using 3rd party libraries. Only Ctrl-C (quit) and debugger signals are
>> used, and a switch from primary to secondary is perfectly acceptable
>> in these two cases.
>
> Yes, signals is a bit of a misnomer, what we actually want is for the
> kernel to be able to cause the execution of an asynchronous callback in
> user-space. For the native skin, it would be for the implementation of
> some hooks. For the posix skin, it would be for the implementation of
> signasl. The implementation of posix timers is based on signals (except
> for SIGEV_THREAD, but who uses SIGEV_THREAD in an rt app...), having
> them cause a switch to secondary mode make them unusable for practical
> purposes. So, with the current version of Xenomai posix skin, you have
> to implement your own timer method, having for instance a thread which
> nanosleep()s until the next timer expiry and then executes the callback.

Ok, but I don't use posix timers for the reasons above. I use
clock_nanosleep instead, which offers the same functionality.

>
>>
>>> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)
>>
>> This is too core for me.
>>
>>> - statistics of all mapped named heaps in /proc/xenomai/heap
>>
>> Don't use heaps since we do all in user space (and I had the
>> impression that heap was for kernel<->user.)
>>
>>> - unwapped access to user-space posix skin methods
>>
>> I wouldn't know why I need this. Do you we link with libpthread
>> instead of libpthread-rt ?
>
> Well the wrap thing is a bit cumbersome. And having the calls be named
> with exactly the posix name is useful only if you intend to compile
> exactly the same code for xenomai and other posix systems. Otherwise,
> you could decide to use a little prefix or suffix to each posix skin
> service, and avoid the wrapping clumsyness.

So like we did in the RTAI days. Maybe we can use rt_ by (safe!)
default and allow a #define in case the users wants to use the
wrapping and is aware that he needs to use the wrapping during
linking.

>
>>
>>> - fast semaphores in user-space
>>
>> I donn't know why I wouldn't need this.
>>
>>> - syscall-less select ?
>>
>> Since a syscall is not per-se bad (?) I also don't see what to win here.
>
> syscall are expensive (which is why we do syscall-less mutexes for
> instance). The idea would be to put the bitfield with the ready file
> descriptors in a shared heap, to avoid going for the syscall if fds are
> already ready when entering select(). The scenario where we would gain
> is on a loaded system, which is exactly when we want to avoid useless
> syscalls.

Then I'm tempted to be in favour, although I'd like to confirm first
that select() is not broken as it is now. Are syscalls expensive
because I'm running Xenomai, or is this the case in vanilla Linux too
? Do we try to be better than Linux (until they use a similar 'fix' in
libc) ?

>
>>
>>> Actually, there are already a lot of things.
>>> So, what do you think?
>>
>> I'm uttermost concerned with stability and to a lesser extent
>> performance. I regard every feature change as changing those two
>> criteria for the worse (unless its a feature that fixes a bug).
>
> Well... I disagree. Even when fixing bugs we can introduce other bugs.
> What matters if you aim for stability and performance is improving the
> tests, not avoiding modifications.

You got me. But until the tests are improved, I beg you to be careful ;-)

Peter

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

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Wed, Sep 30, 2009 at 16:27, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Peter Soetens wrote:
>>> On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> Hi guys,
>>>>
>>>> full of energy after this tremendous first XUM, I would like to start a
>>>> discussion about what people would like to see in the 2.5 branch.
>>> So if we answer positively, we'll delay the release ? I'd rather get
>>> 2.5 out, and develop any new stuff on 2.6. I would also expect that
>>> this list (or part of ) goes to xenomai-help too.
>> The facts are:
>> - our release cycle is long;
>> - we want to keep the ABI stable for each branch.
>> So, anything that we want "soon" and that breaks the ABI should be done
>> in the 2.5 branch, otherwise will have to wait 2.6.
> 
> Ok, but there is stuff in 2.5 I want "soon" too, which you would be delaying.
> 
>>>> Here is a first list, please feel free to criticize it:
>>>> - signals in primary domain (something that we almost forgot)
>>> I refrain from using signals in my apps. They only cause disaster when
>>> using 3rd party libraries. Only Ctrl-C (quit) and debugger signals are
>>> used, and a switch from primary to secondary is perfectly acceptable
>>> in these two cases.
>> Yes, signals is a bit of a misnomer, what we actually want is for the
>> kernel to be able to cause the execution of an asynchronous callback in
>> user-space. For the native skin, it would be for the implementation of
>> some hooks. For the posix skin, it would be for the implementation of
>> signasl. The implementation of posix timers is based on signals (except
>> for SIGEV_THREAD, but who uses SIGEV_THREAD in an rt app...), having
>> them cause a switch to secondary mode make them unusable for practical
>> purposes. So, with the current version of Xenomai posix skin, you have
>> to implement your own timer method, having for instance a thread which
>> nanosleep()s until the next timer expiry and then executes the callback.
> 
> Ok, but I don't use posix timers for the reasons above. I use
> clock_nanosleep instead, which offers the same functionality.

Any sane skin should offer timer services... Using nanosleep is a
workaround for the lack of this feature.

> 
>>>> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)
>>> This is too core for me.
>>>
>>>> - statistics of all mapped named heaps in /proc/xenomai/heap
>>> Don't use heaps since we do all in user space (and I had the
>>> impression that heap was for kernel<->user.)
>>>
>>>> - unwapped access to user-space posix skin methods
>>> I wouldn't know why I need this. Do you we link with libpthread
>>> instead of libpthread-rt ?
>> Well the wrap thing is a bit cumbersome. And having the calls be named
>> with exactly the posix name is useful only if you intend to compile
>> exactly the same code for xenomai and other posix systems. Otherwise,
>> you could decide to use a little prefix or suffix to each posix skin
>> service, and avoid the wrapping clumsyness.
> 
> So like we did in the RTAI days. Maybe we can use rt_ by (safe!)
> default and allow a #define in case the users wants to use the
> wrapping and is aware that he needs to use the wrapping during
> linking.

No, no macros, just aliases at binary level. Probably a separate header too.

> 
>>>> - fast semaphores in user-space
>>> I donn't know why I wouldn't need this.
>>>
>>>> - syscall-less select ?
>>> Since a syscall is not per-se bad (?) I also don't see what to win here.
>> syscall are expensive (which is why we do syscall-less mutexes for
>> instance). The idea would be to put the bitfield with the ready file
>> descriptors in a shared heap, to avoid going for the syscall if fds are
>> already ready when entering select(). The scenario where we would gain
>> is on a loaded system, which is exactly when we want to avoid useless
>> syscalls.
> 
> Then I'm tempted to be in favour, although I'd like to confirm first
> that select() is not broken as it is now. Are syscalls expensive
> because I'm running Xenomai, or is this the case in vanilla Linux too
> ? Do we try to be better than Linux (until they use a similar 'fix' in
> libc) ?

No, syscalls are expensive because they are two context switches from
user-space to kernel-space and back. As for the implementation of
select, Xenomai's implementation is a different trade-off than Linux'es.
Typically, you get O(1) performance, whereas with Linux, you get O(n)
peformance. n being the number of descriptors in the fdset. People will
tell you that it does not matter since user-space scanning the fdset
returned by select is O(n), but it is a much smaller big O (testing a bit).

> 
>>>> Actually, there are already a lot of things.
>>>> So, what do you think?
>>> I'm uttermost concerned with stability and to a lesser extent
>>> performance. I regard every feature change as changing those two
>>> criteria for the worse (unless its a feature that fixes a bug).
>> Well... I disagree. Even when fixing bugs we can introduce other bugs.
>> What matters if you aim for stability and performance is improving the
>> tests, not avoiding modifications.
> 
> You got me. But until the tests are improved, I beg you to be careful ;-)

There is something I realized when watching Niklaus Giger's
presentation, it is that users should distrust the maintainers' testing
and should run their own tests, I think it is a sane behaviour. I do not
mean that we should not improve our testing, but simply that our tests
can not cover the way all users use Xenomai.

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Hi guys,
>>
>> full of energy after this tremendous first XUM, I would like to start a
>> discussion about what people would like to see in the 2.5 branch.
> 
> So if we answer positively, we'll delay the release ? I'd rather get
> 2.5 out, and develop any new stuff on 2.6. I would also expect that
> this list (or part of ) goes to xenomai-help too.

Actually, it is badly expressed. What I would like to know is what
people had in mind, what they intended to put in the 2.5 version, so as
to discuss of what we will put in it and what will be postponed, to have
a more precise idea of the 2.5 development (or end of development, more
precisely, since we already released rc3...) schedule. This comes from
the fact that we had postponed this signals thing, and that it almost
went forgotten, so, I would like to be sure that we do not forget anything.

-- 
                                          Gilles

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

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
>> On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Hi guys,
>>>
>>> full of energy after this tremendous first XUM, I would like to start a
>>> discussion about what people would like to see in the 2.5 branch.
>> So if we answer positively, we'll delay the release ? I'd rather get
>> 2.5 out, and develop any new stuff on 2.6. I would also expect that
>> this list (or part of ) goes to xenomai-help too.
> 
> Actually, it is badly expressed. What I would like to know is what
> people had in mind, what they intended to put in the 2.5 version, so as
> to discuss of what we will put in it and what will be postponed, to have
> a more precise idea of the 2.5 development (or end of development, more
> precisely, since we already released rc3...) schedule. This comes from
> the fact that we had postponed this signals thing, and that it almost
> went forgotten, so, I would like to be sure that we do not forget anything.
> 

We all know the problem here: 2.5 is almost done and should have been
rolled out much earlier, but our resources are limited. Then, 2.5 is
intended to be a long-term maintenance branch, likely the last one in
2.x. Pushing more 2.x features in, enforcing a 2.6 series would make 2.5
an "ordinary" series and, again, require more of our scarce resources.
That would likely be at the expense of long announced 3.0.

We surely can't have all, so we have to pick the best option. Right now
I see the following ones:

 1. Postpone 2.5.0 until all desired ABI-breaking feature are done and
    mature enough.
 2. Release 2.5.0 soon and push the new features into a 2.6 series.
 3. Allow the integration of non-ABI-breaking features into 2.5.1 or
    later (e.g. some heap statistics or unwrapped posix services) and
    develop the other features within 3.0.

My personal prioritization is 3 over 2 over 1. I would really hate to
see 2.5.0 delayed by new features at this point. Also, when looking at
our project with Healthcare, having to wait much longer for 2.5 due to
anything else than bug fixes would complicate things here a lot.

Jan

PS: Hope everyone enjoyed Dresden at least as much like I did. The XUM
was really a great event at the right time!


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

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

[Andreas Glatz]

Hi,

> full of energy after this tremendous first XUM, I would like to start a
> discussion about what people would like to see in the 2.5 branch.

True, it was an great opportunity to see and talk to you guys.


Here is a first list, please feel free to criticize it:
- signals in primary domain (something that we almost forgot)

We don't need that immediately but I think it would be very
handy to have a standard method to register callbacks which are
called once a thread has been signalled and is scheduled.


- xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)

Atomic operations are always good :)

- statistics of all mapped named heaps in /proc/xenomai/heap

That would be very handy from our point of view.

- unwapped access to user-space posix skin methods

We'r using native skin... so I can't say much about that.

- fast semaphores in user-space
- syscall-less select ?

I think, that'd be great. I think that'd help to decrease
the execution time significantly. I haven't told you yet, but I also
have managed to compile and run our Switch application in kernel
space. That decreased the access time to a shared hardware
resource protected by mutexes and using queues by 20% (avg.
access time was 270us in kernel-space instead of 330us in
user-space according to the histograms I generated).


Best regards,
Andreas

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

[Philippe Gerum]

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.

> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs)

This may wait for 2.5.1 and beyond. This is mainly a cosmetic fix for
developers and has no impact on the ABI; we can live with some #ifdef
hell a few months more.

> - statistics of all mapped named heaps in /proc/xenomai/heap

This can wait as well, albeit this is indeed a desirable feature. I
would even export all kind of heaps, since some RTDM drivers like RTIPC
create local heaps, and being able to get their status is very helpful.
It all depends on whether some of us has too much free time in the
coming weeks to make this available in 2.5.0 or later.

> - unwapped access to user-space posix skin methods

I guess that you want to allow people to write/port regular POSIX apps
mostly based on libpthread, and explicitely using libpthread_rt calls
when needed, without any wrapping, which is fair enough, since this may
be easier for merging Xenomai support into hairy legacy code. However,
this can definitely wait after 2.5.0 is out, since this should be a pure
add-on.

> - fast semaphores in user-space

I would rather wait for 3.0, definitely. To do that properly, we would
likely need to share code with the fast mutexes, and I don't think it
would be wise to risk any regression for the latter at that point in the
release cycle. Additionally, I see no absolute urge in terms of
performances to make this feature available; fast mutexes were much more
critical in this respect.

> - syscall-less select ?
> 

Do we really need this? Normally, the typical usage pattern is likely to
be:

for (;;) {
	[rtdm_]select(...);
	<process all pending requests on all active fildes>
}

Which means that once we have fully processed a select() event, we
should not have any pending events anymore, unless in very, very rare
cases where a new notification arrives before the end of processing, and
the point where rtdm_select() puts us to sleep if it sees no active
fildes for us.

I don't see such situation happening that often, otherwise we would
likely have a CPU bandwidth issue down the road, spending most of our
time in a busy loop in primary mode.

So, basically, we would most likely block at least once to get the first
event in a series, then process all reasons for that event to be pending
directly from user-space, hence clearing the reason to be notified
entirely. Testing whether there is a pending event directly from
user-space does not seem that urgent in that case.

> Actually, there are already a lot of things.
> So, what do you think?
> 

I think that we should focus on rolling out 2.5.0 asap.

-- 
Philippe.

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

[Gilles Chanteperdrix]

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
- core skin fdtable

-- 
					    Gilles.

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

[Philippe Gerum]

On Fri, 2009-10-02 at 18:21 +0200, 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
> - core skin fdtable
> 

Ack. Add the following I-pipe stuff as well:

- nios2 design upgrade. Those FPGA thingies require a bit of support to
be included into the soft-core in order to run a real-time system, like
a high precision timer and some stable monotonic clock source. Patrice
Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
sent me an update for the FPGA design I used to do the initial port over
nios2. This is mostly a matter of a couple of hours to fix and validate
the I-pipe core accordingly, though.

- powerpc32 updates for 2.6.30. Mainly to merge the once experimental
bits that prevent most alignment faults from triggering a secondary mode
switch. Andreas told me this works like a charm on 83xx, and I did not
see any issue on 52xx, 85xx or 86xx either.

- probably blackfin updates. I need to have a closer look, but I'm
afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
folks never sleep it seems.

- x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
series.

You may have a few ARM patches brewing as well?

-- 
Philippe.

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

[Gilles Chanteperdrix]

Philippe Gerum wrote:
>> Ok. So, if we add the core skin fdtable, this leaves us with two items:
>> - signals in primary domain
>> - core skin fdtable
>>
> 
> Ack. Add the following I-pipe stuff as well:
> 
> - nios2 design upgrade. Those FPGA thingies require a bit of support to
> be included into the soft-core in order to run a real-time system, like
> a high precision timer and some stable monotonic clock source. Patrice
> Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
> sent me an update for the FPGA design I used to do the initial port over
> nios2. This is mostly a matter of a couple of hours to fix and validate
> the I-pipe core accordingly, though.

Maybe you could ask for a hardware implementation of mul64by64_high...

> 
> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> bits that prevent most alignment faults from triggering a secondary mode
> switch. Andreas told me this works like a charm on 83xx, and I did not
> see any issue on 52xx, 85xx or 86xx either.
> 
> - probably blackfin updates. I need to have a closer look, but I'm
> afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
> folks never sleep it seems.
> 
> - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
> series.
> 
> You may have a few ARM patches brewing as well?

Actually yes. The "pic mute" feature was disabled on AT91 because it was
causing latency peaks, but I plan to enable it ultimately. I think the
latency peaks were due to the fact that I was testing a 2.4 with the bug
which we fixed in 2.4.9.1, I just need to check that. And if pic mute
works on AT91, then I would implement it for other SOCs. And an upgrade
to 2.6.31 would be fine too.

-- 
					    Gilles.

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

[Philippe Gerum]

On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> >> Ok. So, if we add the core skin fdtable, this leaves us with two items:
> >> - signals in primary domain
> >> - core skin fdtable
> >>
> > 
> > Ack. Add the following I-pipe stuff as well:
> > 
> > - nios2 design upgrade. Those FPGA thingies require a bit of support to
> > be included into the soft-core in order to run a real-time system, like
> > a high precision timer and some stable monotonic clock source. Patrice
> > Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
> > sent me an update for the FPGA design I used to do the initial port over
> > nios2. This is mostly a matter of a couple of hours to fix and validate
> > the I-pipe core accordingly, though.
> 
> Maybe you could ask for a hardware implementation of mul64by64_high...

It looks like custom instructions are restricted to input(32bit x 2) =>
output(32bit).

Patrice, do you confirm, or would it be possible to implement such
instruction, that would return the highest 32 bits from a 64 x 64
multiply op? We need this to speed up some arithmetics, especially on a
50Mhz CPU.

If we can't, well, I will likely have to subject myself to write a small
assembly block doing just this, because gcc's output is likely not going
to look like the way Gilles wants.

> 
> > 
> > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > bits that prevent most alignment faults from triggering a secondary mode
> > switch. Andreas told me this works like a charm on 83xx, and I did not
> > see any issue on 52xx, 85xx or 86xx either.
> > 
> > - probably blackfin updates. I need to have a closer look, but I'm
> > afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
> > folks never sleep it seems.
> > 
> > - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
> > series.
> > 
> > You may have a few ARM patches brewing as well?
> 
> Actually yes. The "pic mute" feature was disabled on AT91 because it was
> causing latency peaks, but I plan to enable it ultimately. I think the
> latency peaks were due to the fact that I was testing a 2.4 with the bug
> which we fixed in 2.4.9.1, I just need to check that. And if pic mute
> works on AT91, then I would implement it for other SOCs. And an upgrade
> to 2.6.31 would be fine too.
> 

Ok. How many interrupt controllers would be impacted by the PIC mute
feature?

-- 
Philippe.

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

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>>> Ok. So, if we add the core skin fdtable, this leaves us with two items:
>>>> - signals in primary domain
>>>> - core skin fdtable
>>>>
>>> Ack. Add the following I-pipe stuff as well:
>>>
>>> - nios2 design upgrade. Those FPGA thingies require a bit of support to
>>> be included into the soft-core in order to run a real-time system, like
>>> a high precision timer and some stable monotonic clock source. Patrice
>>> Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
>>> sent me an update for the FPGA design I used to do the initial port over
>>> nios2. This is mostly a matter of a couple of hours to fix and validate
>>> the I-pipe core accordingly, though.
>> Maybe you could ask for a hardware implementation of mul64by64_high...
> 
> It looks like custom instructions are restricted to input(32bit x 2) =>
> output(32bit).
> 
> Patrice, do you confirm, or would it be possible to implement such
> instruction, that would return the highest 32 bits from a 64 x 64
> multiply op? We need this to speed up some arithmetics, especially on a
> 50Mhz CPU.

We want the highest 64 bits. So, you need at least 4 registers. (4
inputs, 2 outputs, but we may assume that the 2 outputs override 2
inputs register).

> 
> If we can't, well, I will likely have to subject myself to write a small
> assembly block doing just this, because gcc's output is likely not going
> to look like the way Gilles wants.

Well, maybe there is a way to modify the plain C version to generate
better code by reducing the number of variables. But that is uncertain
business. Anyway, I do not want anything, if you are happy with the
plain C version, then by all means, keep it. You can measure the time
that the whole thing takes using the unit test.

> 
>>> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
>>> bits that prevent most alignment faults from triggering a secondary mode
>>> switch. Andreas told me this works like a charm on 83xx, and I did not
>>> see any issue on 52xx, 85xx or 86xx either.
>>>
>>> - probably blackfin updates. I need to have a closer look, but I'm
>>> afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
>>> folks never sleep it seems.
>>>
>>> - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
>>> series.
>>>
>>> You may have a few ARM patches brewing as well?
>> Actually yes. The "pic mute" feature was disabled on AT91 because it was
>> causing latency peaks, but I plan to enable it ultimately. I think the
>> latency peaks were due to the fact that I was testing a 2.4 with the bug
>> which we fixed in 2.4.9.1, I just need to check that. And if pic mute
>> works on AT91, then I would implement it for other SOCs. And an upgrade
>> to 2.6.31 would be fine too.
>>
> 
> Ok. How many interrupt controllers would be impacted by the PIC mute
> feature?

Most of the ARM PICs (with their cascaded GPIOs). I have to admit that I
do not keep track of how many arm processors we actually support, but
there's a handful. Or maybe two.


-- 
					    Gilles.

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

[Philippe Gerum]

On Fri, 2009-10-02 at 21:59 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >>>> Ok. So, if we add the core skin fdtable, this leaves us with two items:
> >>>> - signals in primary domain
> >>>> - core skin fdtable
> >>>>
> >>> Ack. Add the following I-pipe stuff as well:
> >>>
> >>> - nios2 design upgrade. Those FPGA thingies require a bit of support to
> >>> be included into the soft-core in order to run a real-time system, like
> >>> a high precision timer and some stable monotonic clock source. Patrice
> >>> Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
> >>> sent me an update for the FPGA design I used to do the initial port over
> >>> nios2. This is mostly a matter of a couple of hours to fix and validate
> >>> the I-pipe core accordingly, though.
> >> Maybe you could ask for a hardware implementation of mul64by64_high...
> > 
> > It looks like custom instructions are restricted to input(32bit x 2) =>
> > output(32bit).
> > 
> > Patrice, do you confirm, or would it be possible to implement such
> > instruction, that would return the highest 32 bits from a 64 x 64
> > multiply op? We need this to speed up some arithmetics, especially on a
> > 50Mhz CPU.
> 
> We want the highest 64 bits.

Yep, just noticed the glitch.

>  So, you need at least 4 registers. (4
> inputs, 2 outputs, but we may assume that the 2 outputs override 2
> inputs register).
> 
> > 
> > If we can't, well, I will likely have to subject myself to write a small
> > assembly block doing just this, because gcc's output is likely not going
> > to look like the way Gilles wants.
> 
> Well, maybe there is a way to modify the plain C version to generate
> better code by reducing the number of variables. But that is uncertain
> business. Anyway, I do not want anything, if you are happy with the
> plain C version, then by all means, keep it. You can measure the time
> that the whole thing takes using the unit test.
> 

Looking at the output of the arith unit test, gcc did not seem to be
that efficient producing code for llimd and friends, so I doubt we could
spare having nodiv_ullimd rewrote.

> > 
> >>> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> >>> bits that prevent most alignment faults from triggering a secondary mode
> >>> switch. Andreas told me this works like a charm on 83xx, and I did not
> >>> see any issue on 52xx, 85xx or 86xx either.
> >>>
> >>> - probably blackfin updates. I need to have a closer look, but I'm
> >>> afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
> >>> folks never sleep it seems.
> >>>
> >>> - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
> >>> series.
> >>>
> >>> You may have a few ARM patches brewing as well?
> >> Actually yes. The "pic mute" feature was disabled on AT91 because it was
> >> causing latency peaks, but I plan to enable it ultimately. I think the
> >> latency peaks were due to the fact that I was testing a 2.4 with the bug
> >> which we fixed in 2.4.9.1, I just need to check that. And if pic mute
> >> works on AT91, then I would implement it for other SOCs. And an upgrade
> >> to 2.6.31 would be fine too.
> >>
> > 
> > Ok. How many interrupt controllers would be impacted by the PIC mute
> > feature?
> 
> Most of the ARM PICs (with their cascaded GPIOs). I have to admit that I
> do not keep track of how many arm processors we actually support, but
> there's a handful. Or maybe two.
> 
> 
-- 
Philippe.

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

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Ok. How many interrupt controllers would be impacted by the PIC mute
>> feature?
> 
> Most of the ARM PICs (with their cascaded GPIOs). I have to admit that I
> do not keep track of how many arm processors we actually support, but
> there's a handful. Or maybe two.

We support 9 arm SOCs families.

-- 
					    Gilles.

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

[Philippe Gerum]

On Fri, 2009-10-02 at 22:25 +0200, Patrice Kadionik wrote:
> Hi all,
> Philippe Gerum a écrit : 
> > On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
> >   
> > > Philippe Gerum wrote:
> > >     
> > > > > Ok. So, if we add the core skin fdtable, this leaves us with two items:
> > > > > - signals in primary domain
> > > > > - core skin fdtable
> > > > > 
> > > > >         
> > > > Ack. Add the following I-pipe stuff as well:
> > > > 
> > > > - nios2 design upgrade. Those FPGA thingies require a bit of support to
> > > > be included into the soft-core in order to run a real-time system, like
> > > > a high precision timer and some stable monotonic clock source. Patrice
> > > > Kadionik (the guy who lives there: http://uuu.enseirb.fr/~kadionik/)
> > > > sent me an update for the FPGA design I used to do the initial port over
> > > > nios2. This is mostly a matter of a couple of hours to fix and validate
> > > > the I-pipe core accordingly, though.
> > > >       
> > > Maybe you could ask for a hardware implementation of mul64by64_high...
> > >     
> > 
> > It looks like custom instructions are restricted to input(32bit x 2) =>
> > output(32bit).
> >   
> Yes you're right. Just 32-bit HW multipliers at this time for the NIOS
> II softcore.
> > Patrice, do you confirm, or would it be possible to implement such
> > instruction, that would return the highest 32 bits from a 64 x 64
> > multiply op? We need this to speed up some arithmetics, especially on a
> > 50Mhz CPU.
> > 
> >   
> Yes, it would be always possible to develop such a specific multiplier
> in VHDL . I just have a doubt to integrate it as a NIOS II custom
> instruction...
> > If we can't, well, I will likely have to subject myself to write a small
> > assembly block doing just this, because gcc's output is likely not going
> > to look like the way Gilles wants.
> > 
> >   
> You have in the NIOS II Instruction Set Reference the multiply
> extended (mulxuu...) instruction for this at this time.
> 

Ok, let's go the assembly way.

> 
> Cheers,
> 
> Patrice
> > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > see any issue on 52xx, 85xx or 86xx either.
> > > > 
> > > > - probably blackfin updates. I need to have a closer look, but I'm
> > > > afraid I will have to resync with mainline before 2.5.0 is out. Blackfin
> > > > folks never sleep it seems.
> > > > 
> > > > - x86* updates to issue patches for the 2.6.30-stable and 2.6.31-stable
> > > > series.
> > > > 
> > > > You may have a few ARM patches brewing as well?
> > > >       
> > > Actually yes. The "pic mute" feature was disabled on AT91 because it was
> > > causing latency peaks, but I plan to enable it ultimately. I think the
> > > latency peaks were due to the fact that I was testing a 2.4 with the bug
> > > which we fixed in 2.4.9.1, I just need to check that. And if pic mute
> > > works on AT91, then I would implement it for other SOCs. And an upgrade
> > > to 2.6.31 would be fine too.
> > > 
> > >     
> > 
> > Ok. How many interrupt controllers would be impacted by the PIC mute
> > feature?
> > 
> >   
> 
-- 
Philippe.

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

[Andreas Glatz]

> 
> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> bits that prevent most alignment faults from triggering a secondary mode
> switch. Andreas told me this works like a charm on 83xx, and I did not
> see any issue on 52xx, 85xx or 86xx either.
> 

Can I get a version of that patch for testing? Is it in your git
repository?

Andreas

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

[Philippe Gerum]

On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > 
> > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > bits that prevent most alignment faults from triggering a secondary mode
> > switch. Andreas told me this works like a charm on 83xx, and I did not
> > see any issue on 52xx, 85xx or 86xx either.
> > 
> 
> Can I get a version of that patch for testing? Is it in your git
> repository?

I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
branch); it should appear in a few hours once mirrored (cron job).

> 
> Andreas
-- 
Philippe.

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

[Wolfgang Denk]

Dear Philippe Gerum,

In message <1254510029.2703.355.camel@domain.hid> you wrote:
>
> I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> branch); it should appear in a few hours once mirrored (cron job).

It's out (I manually triggered a sync :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

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

[Philippe Gerum]

On Fri, 2009-10-02 at 21:39 +0200, Wolfgang Denk wrote:
> Dear Philippe Gerum,
> 
> In message <1254510029.2703.355.camel@domain.hid> you wrote:
> >
> > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > branch); it should appear in a few hours once mirrored (cron job).
> 
> It's out (I manually triggered a sync :-)*

Thanks.

> 
> Best regards,
> 
> Wolfgang Denk
> 
-- 
Philippe.

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

[Andreas Glatz]

On Fri, 2009-10-02 at 21:00 +0200, Philippe Gerum wrote:
> On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > > 
> > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > bits that prevent most alignment faults from triggering a secondary mode
> > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > see any issue on 52xx, 85xx or 86xx either.
> > > 
> > 
> > Can I get a version of that patch for testing? Is it in your git
> > repository?
> 
> I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> branch); it should appear in a few hours once mirrored (cron job).
> 

I finally had a chance to test the ipipe-2.6.30-powerpc version
from the git repository. Unfortunately, I noticed that our application
dies after some time and that this behaviour is related to that 
alignment patch (if I take it out everything runs fine for > 2 days).

Currently I'm investigating the reasons for that crash. It has
something to do with floating point registers not being restored
properly. Our alignment exceptions are mainly triggered by accesses 
to unaligned floating point data.

Andreas

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

[Philippe Gerum]

On Tue, 2009-10-06 at 14:26 -0400, Andreas Glatz wrote:
> On Fri, 2009-10-02 at 21:00 +0200, Philippe Gerum wrote:
> > On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > > > 
> > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > see any issue on 52xx, 85xx or 86xx either.
> > > > 
> > > 
> > > Can I get a version of that patch for testing? Is it in your git
> > > repository?
> > 
> > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > branch); it should appear in a few hours once mirrored (cron job).
> > 
> 
> I finally had a chance to test the ipipe-2.6.30-powerpc version
> from the git repository. Unfortunately, I noticed that our application
> dies after some time and that this behaviour is related to that 
> alignment patch (if I take it out everything runs fine for > 2 days).
> 
> Currently I'm investigating the reasons for that crash. It has
> something to do with floating point registers not being restored
> properly. Our alignment exceptions are mainly triggered by accesses 
> to unaligned floating point data.
> 

Just to check some assumption of mine, could you try running with
CONFIG_PREEMPT off (+patch) if this is not the case yet? TIA,

> Andreas
-- 
Philippe.

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

[Philippe Gerum]

On Tue, 2009-10-06 at 14:26 -0400, Andreas Glatz wrote:
> On Fri, 2009-10-02 at 21:00 +0200, Philippe Gerum wrote:
> > On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > > > 
> > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > see any issue on 52xx, 85xx or 86xx either.
> > > > 
> > > 
> > > Can I get a version of that patch for testing? Is it in your git
> > > repository?
> > 
> > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > branch); it should appear in a few hours once mirrored (cron job).
> > 
> 
> I finally had a chance to test the ipipe-2.6.30-powerpc version
> from the git repository. Unfortunately, I noticed that our application
> dies after some time and that this behaviour is related to that 
> alignment patch (if I take it out everything runs fine for > 2 days).
> 
> Currently I'm investigating the reasons for that crash. It has
> something to do with floating point registers not being restored
> properly. Our alignment exceptions are mainly triggered by accesses 
> to unaligned floating point data.

Does it work any better with this patch in?

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 32cc3df..a04a5e3 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -80,7 +80,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
 		 * FPU, and then when we get scheduled again we would store
 		 * bogus values for the remaining FP registers.
 		 */
-		ipipe_preempt_disable(flags);
+		if (ipipe_root_domain_p)
+			preempt_disable();
+		local_irq_save_hw_cond(flags);
 		if (tsk->thread.regs->msr & MSR_FP) {
 #ifdef CONFIG_SMP
 			/*
@@ -94,7 +96,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
 #endif
 			giveup_fpu(tsk);
 		}
- 		ipipe_preempt_enable(flags);
+		local_irq_restore_hw_cond(flags);
+		if (ipipe_root_domain_p)
+			preempt_enable();
 	}
 }
 

> 
> Andreas
-- 
Philippe.

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

[Andreas Glatz]

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

Hi Philippe,

Back at work. See inline replies below.


> > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > > see any issue on 52xx, 85xx or 86xx either.
> > > > >
> > > >
> > > > Can I get a version of that patch for testing? Is it in your git
> > > > repository?
> > >
> > > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > > branch); it should appear in a few hours once mirrored (cron job).
> > >
> >
> > I finally had a chance to test the ipipe-2.6.30-powerpc version
> > from the git repository. Unfortunately, I noticed that our application
> > dies after some time and that this behaviour is related to that
> > alignment patch (if I take it out everything runs fine for > 2 days).
> >
> > Currently I'm investigating the reasons for that crash. It has
> > something to do with floating point registers not being restored
> > properly. Our alignment exceptions are mainly triggered by accesses
> > to unaligned floating point data.
> 
> Does it work any better with this patch in?

I applied that patch but unfortunately our application still dies. I included
an application with with you (hopefully) can reproduce the problem 
which we are seeing. Our system is a MPC8360 with 2.6.30, ipipe 2.7,
xenomai 2.4.9.1.

Here are the steps:

1) apply ipipe with alignment patch, recompile kernel
2) comile test1.c (attached) with: 
        gcc -Wall -O2 `xeno-config --xeno-cflags` \
                                `xeno-config --xeno-ldflags` \
                                 -l native -l rtdk  -o test1 test1.c
3) Start test1 in one shell
4) Open a second shell and start 'switchbench'

Just when 'switchbench' is running, I get the following
output from my test application:
...
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000 
...

It seems that test1 is interrupted right between
the lfd and stfd and the floating point regs aren't
restored properly.

Just a side note: I had to add assembly code to my
C program to force an alignment exception. gcc seems
to be smart enough to avoid unaligned access. g++
on the other hand (especially g++ 3.3.6 which we are 
using) seems to generate assembly code which causes
alignment exceptions. So it seems that it's really g++'s 
fault. We also discovered that our g++ generates buggy 
floating point assembly code when compiling with the 
-O2 or -Os option. Currently, we compile our application
with -msoft-float to avoid those issues which has the
nice side effect that we also don't get alignment exceptions
anymore.

Many thanks,
Andreas


> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 32cc3df..a04a5e3 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -80,7 +80,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
>                  * FPU, and then when we get scheduled again we would store
>                  * bogus values for the remaining FP registers.
>                  */
> -               ipipe_preempt_disable(flags);
> +               if (ipipe_root_domain_p)
> +                       preempt_disable();
> +               local_irq_save_hw_cond(flags);
>                 if (tsk->thread.regs->msr & MSR_FP) {
>  #ifdef CONFIG_SMP
>                         /*
> @@ -94,7 +96,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
>  #endif
>                         giveup_fpu(tsk);
>                 }
> -               ipipe_preempt_enable(flags);
> +               local_irq_restore_hw_cond(flags);
> +               if (ipipe_root_domain_p)
> +                       preempt_enable();
>         }
>  }

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test1.c --]
[-- Type: text/x-csrc; name="test1.c", Size: 1227 bytes --]

/* vim: set ts = 4: */
#include <sys/mman.h>
#include <unistd.h>
#include <signal.h>
#include <string.h>
#include <stdarg.h>
#include <rtdk.h>
#include <native/task.h>

typedef struct msg {
	unsigned char id;
	union {
		unsigned long long raw;
		struct {
			unsigned short val1;
			unsigned long val2;
			unsigned short val3;
		} __attribute__((packed));
	};
} __attribute__((packed)) msg_t;

static RT_TASK task;
static msg_t msg;

int main(void)
{
	int err;

	mlockall(MCL_CURRENT|MCL_FUTURE);
	rt_print_auto_init(1);

	err = rt_task_shadow(&task, "main", 3, 0);
	if(!err) {
		/* Fill the message */
		msg.id = 0xFF;
		msg.val1 = 0x1234;
		msg.val2 = 0x56789ABC;
		msg.val3 = 0xDEF0;

		while(1) {
			double save;
			unsigned long long out = 0;

			/* Force an alignment exception
			   by accessing unaligned floating
			   point data (lfd 0,1(%2)). */
			__asm__ __volatile__(
			"stfd 0,%0   # save contents of f0 \n\t"
			"lfd 0,1(%2) # unaligned access \n\t"
			"stfd 0,%1   # store data in 'out' \n\t"
			"lfd 0,%0    # restore contents of f0 \n\t" 
			: "=m"(save), "=m"(out)
			: "r"(&msg)
			);

			if( out != msg.raw )
				rt_printf("Missmatch: 0x%llx\n", out);

			rt_task_sleep(100000ULL);
		}
	}
	return err;
}

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

[Philippe Gerum]

On Thu, 2009-10-15 at 15:21 -0400, Andreas Glatz wrote:
> Hi Philippe,
> 
> Back at work. See inline replies below.
> 
> 
> > > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > > > see any issue on 52xx, 85xx or 86xx either.
> > > > > >
> > > > >
> > > > > Can I get a version of that patch for testing? Is it in your git
> > > > > repository?
> > > >
> > > > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > > > branch); it should appear in a few hours once mirrored (cron job).
> > > >
> > >
> > > I finally had a chance to test the ipipe-2.6.30-powerpc version
> > > from the git repository. Unfortunately, I noticed that our application
> > > dies after some time and that this behaviour is related to that
> > > alignment patch (if I take it out everything runs fine for > 2 days).
> > >
> > > Currently I'm investigating the reasons for that crash. It has
> > > something to do with floating point registers not being restored
> > > properly. Our alignment exceptions are mainly triggered by accesses
> > > to unaligned floating point data.
> > 
> > Does it work any better with this patch in?
> 
> I applied that patch but unfortunately our application still dies. I included
> an application with with you (hopefully) can reproduce the problem 
> which we are seeing. Our system is a MPC8360 with 2.6.30, ipipe 2.7,
> xenomai 2.4.9.1.
> 

Confirmed on lite52xx as well. Will work on this.

> Here are the steps:
> 
> 1) apply ipipe with alignment patch, recompile kernel
> 2) comile test1.c (attached) with: 
>         gcc -Wall -O2 `xeno-config --xeno-cflags` \
>                                 `xeno-config --xeno-ldflags` \
>                                  -l native -l rtdk  -o test1 test1.c
> 3) Start test1 in one shell
> 4) Open a second shell and start 'switchbench'
> 
> Just when 'switchbench' is running, I get the following
> output from my test application:
> ...
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000 
> ...
> 
> It seems that test1 is interrupted right between
> the lfd and stfd and the floating point regs aren't
> restored properly.
> 
> Just a side note: I had to add assembly code to my
> C program to force an alignment exception. gcc seems
> to be smart enough to avoid unaligned access. g++
> on the other hand (especially g++ 3.3.6 which we are 
> using) seems to generate assembly code which causes
> alignment exceptions. So it seems that it's really g++'s 
> fault. We also discovered that our g++ generates buggy 
> floating point assembly code when compiling with the 
> -O2 or -Os option. Currently, we compile our application
> with -msoft-float to avoid those issues which has the
> nice side effect that we also don't get alignment exceptions
> anymore.
> 
> Many thanks,
> Andreas
> 
> 
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 32cc3df..a04a5e3 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -80,7 +80,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
> >                  * FPU, and then when we get scheduled again we would store
> >                  * bogus values for the remaining FP registers.
> >                  */
> > -               ipipe_preempt_disable(flags);
> > +               if (ipipe_root_domain_p)
> > +                       preempt_disable();
> > +               local_irq_save_hw_cond(flags);
> >                 if (tsk->thread.regs->msr & MSR_FP) {
> >  #ifdef CONFIG_SMP
> >                         /*
> > @@ -94,7 +96,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
> >  #endif
> >                         giveup_fpu(tsk);
> >                 }
> > -               ipipe_preempt_enable(flags);
> > +               local_irq_restore_hw_cond(flags);
> > +               if (ipipe_root_domain_p)
> > +                       preempt_enable();
> >         }
> >  }
-- 
Philippe.

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

[Philippe Gerum]

On Thu, 2009-10-15 at 15:21 -0400, Andreas Glatz wrote:
> Hi Philippe,
> 
> Back at work. See inline replies below.
> 
> 
> > > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > > > see any issue on 52xx, 85xx or 86xx either.
> > > > > >
> > > > >
> > > > > Can I get a version of that patch for testing? Is it in your git
> > > > > repository?
> > > >
> > > > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > > > branch); it should appear in a few hours once mirrored (cron job).
> > > >
> > >
> > > I finally had a chance to test the ipipe-2.6.30-powerpc version
> > > from the git repository. Unfortunately, I noticed that our application
> > > dies after some time and that this behaviour is related to that
> > > alignment patch (if I take it out everything runs fine for > 2 days).
> > >
> > > Currently I'm investigating the reasons for that crash. It has
> > > something to do with floating point registers not being restored
> > > properly. Our alignment exceptions are mainly triggered by accesses
> > > to unaligned floating point data.
> > 
> > Does it work any better with this patch in?
> 
> I applied that patch but unfortunately our application still dies. I included
> an application with with you (hopefully) can reproduce the problem 
> which we are seeing. Our system is a MPC8360 with 2.6.30, ipipe 2.7,
> xenomai 2.4.9.1.
> 
> Here are the steps:
> 
> 1) apply ipipe with alignment patch, recompile kernel
> 2) comile test1.c (attached) with: 
>         gcc -Wall -O2 `xeno-config --xeno-cflags` \
>                                 `xeno-config --xeno-ldflags` \
>                                  -l native -l rtdk  -o test1 test1.c
> 3) Start test1 in one shell
> 4) Open a second shell and start 'switchbench'
> 
> Just when 'switchbench' is running, I get the following
> output from my test application:
> ...
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000
> Missmatch: 0xfff8000082064000 
> ...

There is a serious issue going on with this patch, because this
optimization depends on the ability of Xenomai to properly handle
non-linux, non-RT FPU usage in kernel space, which is not guaranteed so
far for powerpc (x86 is ok regarding this, though).

So I'm just reverting this patch, in order to get back to a correct
behavior asap. This will require more thoughts later, when 2.5.0 is out.
Sorry for the delay.

> 
> It seems that test1 is interrupted right between
> the lfd and stfd and the floating point regs aren't
> restored properly.
> 
> Just a side note: I had to add assembly code to my
> C program to force an alignment exception. gcc seems
> to be smart enough to avoid unaligned access. g++
> on the other hand (especially g++ 3.3.6 which we are 
> using) seems to generate assembly code which causes
> alignment exceptions. So it seems that it's really g++'s 
> fault. We also discovered that our g++ generates buggy 
> floating point assembly code when compiling with the 
> -O2 or -Os option. Currently, we compile our application
> with -msoft-float to avoid those issues which has the
> nice side effect that we also don't get alignment exceptions
> anymore.
> 
> Many thanks,
> Andreas
> 
> 
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 32cc3df..a04a5e3 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -80,7 +80,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
> >                  * FPU, and then when we get scheduled again we would store
> >                  * bogus values for the remaining FP registers.
> >                  */
> > -               ipipe_preempt_disable(flags);
> > +               if (ipipe_root_domain_p)
> > +                       preempt_disable();
> > +               local_irq_save_hw_cond(flags);
> >                 if (tsk->thread.regs->msr & MSR_FP) {
> >  #ifdef CONFIG_SMP
> >                         /*
> > @@ -94,7 +96,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
> >  #endif
> >                         giveup_fpu(tsk);
> >                 }
> > -               ipipe_preempt_enable(flags);
> > +               local_irq_restore_hw_cond(flags);
> > +               if (ipipe_root_domain_p)
> > +                       preempt_enable();
> >         }
> >  }
-- 
Philippe.

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

[Andreas Glatz]

> >
> > > > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > > > > see any issue on 52xx, 85xx or 86xx either.
> > > > > > >
> > > > > >
> > > > > > Can I get a version of that patch for testing? Is it in your git
> > > > > > repository?
> > > > >
> > > > > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > > > > branch); it should appear in a few hours once mirrored (cron job).
> > > > >
> > > >
> > > > I finally had a chance to test the ipipe-2.6.30-powerpc version
> > > > from the git repository. Unfortunately, I noticed that our application
> > > > dies after some time and that this behaviour is related to that
> > > > alignment patch (if I take it out everything runs fine for > 2 days).
> > > >
> > > > Currently I'm investigating the reasons for that crash. It has
> > > > something to do with floating point registers not being restored
> > > > properly. Our alignment exceptions are mainly triggered by accesses
> > > > to unaligned floating point data.
> > >
> > > Does it work any better with this patch in?
> >
> > I applied that patch but unfortunately our application still dies. I included
> > an application with with you (hopefully) can reproduce the problem
> > which we are seeing. Our system is a MPC8360 with 2.6.30, ipipe 2.7,
> > xenomai 2.4.9.1.
> >
> > Here are the steps:
> >
> > 1) apply ipipe with alignment patch, recompile kernel
> > 2) comile test1.c (attached) with:
> >         gcc -Wall -O2 `xeno-config --xeno-cflags` \
> >                                 `xeno-config --xeno-ldflags` \
> >                                  -l native -l rtdk  -o test1 test1.c
> > 3) Start test1 in one shell
> > 4) Open a second shell and start 'switchbench'
> >
> > Just when 'switchbench' is running, I get the following
> > output from my test application:
> > ...
> > Missmatch: 0xfff8000082064000
> > Missmatch: 0xfff8000082064000
> > Missmatch: 0xfff8000082064000
> > Missmatch: 0xfff8000082064000
> > ...
> 
> There is a serious issue going on with this patch, because this
> optimization depends on the ability of Xenomai to properly handle
> non-linux, non-RT FPU usage in kernel space, which is not guaranteed so
> far for powerpc (x86 is ok regarding this, though).
> 
> So I'm just reverting this patch, in order to get back to a correct
> behavior asap. This will require more thoughts later, when 2.5.0 is out.
> Sorry for the delay.
> 

No worries Philippe... that's just one of a number of pending issues :p

Thanks again for your help,
Andreas

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

[Philippe Gerum]

On Tue, 2009-10-06 at 14:26 -0400, Andreas Glatz wrote:
> On Fri, 2009-10-02 at 21:00 +0200, Philippe Gerum wrote:
> > On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > > > 
> > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > bits that prevent most alignment faults from triggering a secondary mode
> > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > see any issue on 52xx, 85xx or 86xx either.
> > > > 
> > > 
> > > Can I get a version of that patch for testing? Is it in your git
> > > repository?
> > 
> > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > branch); it should appear in a few hours once mirrored (cron job).
> > 
> 
> I finally had a chance to test the ipipe-2.6.30-powerpc version
> from the git repository. Unfortunately, I noticed that our application
> dies after some time and that this behaviour is related to that 
> alignment patch (if I take it out everything runs fine for > 2 days).
> 
> Currently I'm investigating the reasons for that crash. It has
> something to do with floating point registers not being restored
> properly. Our alignment exceptions are mainly triggered by accesses 
> to unaligned floating point data.
> 

This patch fixes an issue I have just discovered when running two
switchtest programs concurrently on 52xx; that issue was introduced by
the no-switch-upon-alignment patch. The bug you saw may be related.

http://download.gna.org/adeos/patches/v2.6/powerpc/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-01.patch

> Andreas
-- 
Philippe.

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

[Jan Kiszka]

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

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.

> - core skin fdtable

If we can find a minimally invasive first version (see other thread)
that can be tested and stabilized within very few weeks, and later
changes will definitely only touch core code, I might be able to live
with this for 2.5.

Jan


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

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

[Philippe Gerum]

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.

> > - core skin fdtable
> 
> If we can find a minimally invasive first version (see other thread)
> that can be tested and stabilized within very few weeks, and later
> changes will definitely only touch core code, I might be able to live
> with this for 2.5.
> 
> Jan
> 
-- 
Philippe.

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

[Jan Kiszka]

[-- 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 --]