[Xenomai-core] Xenomai 2.6.0, or -rc1?

[Xenomai-core] Xenomai 2.6.0, or -rc1?

[Gilles Chanteperdrix]

Hi,

I think it is about time we release Xenomai 2.6.0. Has anyone anything
pending (maybe Alex)? Should we release an -rc first?

Thanks in advance for your input.

-- 
					    Gilles.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Jan Kiszka]

On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
> 
> Hi,
> 
> I think it is about time we release Xenomai 2.6.0. Has anyone anything
> pending (maybe Alex)? Should we release an -rc first?

No patches ATM, but [1] is still an open bug - a bug that affects the ABI.

Jan

[1] http://thread.gmane.org/gmane.linux.real-time.xenomai.devel/8343

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Philippe Gerum]

On Fri, 2011-08-26 at 14:34 +0200, Gilles Chanteperdrix wrote:
> Hi,
> 
> I think it is about time we release Xenomai 2.6.0. Has anyone anything
> pending (maybe Alex)? Should we release an -rc first?
> 
> Thanks in advance for your input.
> 


Nothing pending for 2.6, I'm focusing on 3.x now. However let's go for
-rc1 first, this is a major release anyway.

-- 
Philippe.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Gilles Chanteperdrix]

On 08/26/2011 03:05 PM, Jan Kiszka wrote:
> On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>> pending (maybe Alex)? Should we release an -rc first?
> 
> No patches ATM, but [1] is still an open bug - a bug that affects the ABI.
> 
> Jan
> 
> [1] http://thread.gmane.org/gmane.linux.real-time.xenomai.devel/8343
> 

I had forgotten about this one. So, the only real problem is if a
SCHED_NOTOTHER thread switches to SCHED_OTHER, this appears to be a
corner case, so, I wonder if you should not simply add a special
treatment, only for this corner case.

What I have in mind is keeping a list of xnsynch in kernel-space (this
basically means having an xnholder_t more in the xnsynch structure), and
when we trip the corner case (thread with SCHED_FIFO switches to
SCHED_OTHER), walk the list to find how many xnsynch the thread is the
owner, we have that info in kernel-space, and set the refcnt accordingly.

Or does it still sound overkill?


-- 
                                                                Gilles.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Jan Kiszka]

On 2011-08-26 20:07, Gilles Chanteperdrix wrote:
> On 08/26/2011 03:05 PM, Jan Kiszka wrote:
>> On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
>>>
>>> Hi,
>>>
>>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>>> pending (maybe Alex)? Should we release an -rc first?
>>
>> No patches ATM, but [1] is still an open bug - a bug that affects the ABI.
>>
>> Jan
>>
>> [1] http://thread.gmane.org/gmane.linux.real-time.xenomai.devel/8343
>>
> 
> I had forgotten about this one. So, the only real problem is if a
> SCHED_NOTOTHER thread switches to SCHED_OTHER, this appears to be a
> corner case, so, I wonder if you should not simply add a special
> treatment, only for this corner case.
> 
> What I have in mind is keeping a list of xnsynch in kernel-space (this
> basically means having an xnholder_t more in the xnsynch structure), and
> when we trip the corner case (thread with SCHED_FIFO switches to
> SCHED_OTHER), walk the list to find how many xnsynch the thread is the
> owner, we have that info in kernel-space, and set the refcnt accordingly.
> 
> Or does it still sound overkill?
> 

Mmh, need to think about it. Yeah, we do not support
PTHREAD_MUTEX_INITIALIZER, so we do not share that part of the problem
with futexes.

If we have all objects and can explore ownership, we can also implement
robust mutexes this way, i.e. waiter signaling when the owner dies.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Gilles Chanteperdrix]

On 08/26/2011 08:19 PM, Jan Kiszka wrote:
> On 2011-08-26 20:07, Gilles Chanteperdrix wrote:
>> On 08/26/2011 03:05 PM, Jan Kiszka wrote:
>>> On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>>>> pending (maybe Alex)? Should we release an -rc first?
>>>
>>> No patches ATM, but [1] is still an open bug - a bug that affects the ABI.
>>>
>>> Jan
>>>
>>> [1] http://thread.gmane.org/gmane.linux.real-time.xenomai.devel/8343
>>>
>>
>> I had forgotten about this one. So, the only real problem is if a
>> SCHED_NOTOTHER thread switches to SCHED_OTHER, this appears to be a
>> corner case, so, I wonder if you should not simply add a special
>> treatment, only for this corner case.
>>
>> What I have in mind is keeping a list of xnsynch in kernel-space (this
>> basically means having an xnholder_t more in the xnsynch structure), and
>> when we trip the corner case (thread with SCHED_FIFO switches to
>> SCHED_OTHER), walk the list to find how many xnsynch the thread is the
>> owner, we have that info in kernel-space, and set the refcnt accordingly.
>>
>> Or does it still sound overkill?
>>
> 
> Mmh, need to think about it. Yeah, we do not support
> PTHREAD_MUTEX_INITIALIZER, so we do not share that part of the problem
> with futexes.

Actually, we could implement PTHREAD_MUTEX_INITIALIZER: when the magic
is wrong, just issue a pthread_mutex_init syscall, and try locking
again. But the problem is that this particular call to
pthread_mutex_lock would be much heavier than locking an initialized
mutex for reasons which are not obvious (besides, we would have to
handle concurrency by some way, like having a pthread_once_t in
pthread_mutex_t). I find not having PTHREAD_MUTEX_INITIALIZER more
clear, even if this makes us not really posix compliant.

> 
> If we have all objects and can explore ownership, we can also implement
> robust mutexes this way, i.e. waiter signaling when the owner dies.
> 
> Jan
> 


-- 
                                                                Gilles.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Alexis Berlemont]

Hi,

On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> Hi,
>
> I think it is about time we release Xenomai 2.6.0. Has anyone anything
> pending (maybe Alex)? Should we release an -rc first?
>
Yes. in my experimental branch, I have a few things which are not that
experimental. I would like to push:
- a first version of Julien Delange's ni_660x driver
- Anders Blomdell's fix on duplicate sympbols with comedi
- Anders Blomdell's fix in pcimio driver (wrong IRQ number after reboot)
- some waveform generation tools (fully generic)
- an overhaul of the testing drivers (fake + loop => fake)

I will integrate them in my analogy branch and send a pull request if
you are OK with that.

Alexis.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Gilles Chanteperdrix]

On 08/30/2011 01:00 AM, Alexis Berlemont wrote:
> Hi,
> 
> On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>> Hi,
>>
>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>> pending (maybe Alex)? Should we release an -rc first?
>>
> Yes. in my experimental branch, I have a few things which are not that
> experimental. I would like to push:
> - a first version of Julien Delange's ni_660x driver
> - Anders Blomdell's fix on duplicate sympbols with comedi
> - Anders Blomdell's fix in pcimio driver (wrong IRQ number after reboot)
> - some waveform generation tools (fully generic)
> - an overhaul of the testing drivers (fake + loop => fake)
> 
> I will integrate them in my analogy branch and send a pull request if
> you are OK with that.

Ok for me.


-- 
                                                                Gilles.

Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?

[Julien Delange]

On Tue, Aug 30, 2011 at 1:00 AM, Alexis Berlemont
<alexis.berlemont@domain.hid> wrote:
> - a first version of Julien Delange's ni_660x driver

And also the one for the 670x board, no ?