Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
On 08/30/2011 01:00 AM, Alexis Berlemont wrote: Hi, On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix gilles.chanteperd...@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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
On Tue, Aug 30, 2011 at 1:00 AM, Alexis Berlemont alexis.berlem...@gmail.com wrote: - a first version of Julien Delange's ni_660x driver And also the one for the 670x board, no ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
Hi, On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix gilles.chanteperd...@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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
