Dear Gilles Chanteperdrix,
In message <497f6524.2080...@xenomai.org> you wrote:
>
> So, the question is: are there people around who either:
> - need FPU support for kernel-space real-time threads;
> - do not want to pay the price of a trap when using the FPU in user-space.
My gut feeling (and t
Gilles Chanteperdrix wrote:
> Paul wrote:
>> Hi Giles
>>
>> On Tuesday 27 January 2009, Gilles Chanteperdrix wrote:
>>> So, the question is: are there people around who either:
>>> - need FPU support for kernel-space real-time threads;
>>> - do not want to pay the price of a trap when using the FPU
Paul wrote:
> Hi Giles
>
> On Tuesday 27 January 2009, Gilles Chanteperdrix wrote:
>> So, the question is: are there people around who either:
>> - need FPU support for kernel-space real-time threads;
>> - do not want to pay the price of a trap when using the FPU in user-space.
>
> One applicatio
Hi Giles
On Tuesday 27 January 2009, Gilles Chanteperdrix wrote:
> So, the question is: are there people around who either:
> - need FPU support for kernel-space real-time threads;
> - do not want to pay the price of a trap when using the FPU in user-space.
One application that I work on uses fl
Hi,
having to work on twice consecutive FPU issues made me think a bit about
the situation of FPU support in Xenomai.
What makes our FPU support code so complex? It is the fact that we
support eager FPU context save/restore for both user-space and
kernel-space real-time threads which ask it whil
Last resend before removal of the ia64 support.
Philippe Gerum wrote:
> It has been 2.5 years since we saw an update to the Xenomai/ia64 port, and
> there
> is still no sign of life coming from ia64 users (do we actually have any
> Xenomai/ia64 users? maybe one, a single one?). To sum up the sit
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> This is an attempt to fix the bugs found in the minor number management:
>> - changing the bitmap requires atomic operations
>> - clrbits/setbits work against xnarch_atomic_t, and that is only 32 bit
>> wide on x86-64
>
> I think we should rathe
Gilles Chanteperdrix wrote:
> As for the find_first_bit, why not simply taking the nklock
in
> xnpipe_minor_free ? This is a first masking section, so this should not
> matter a lot.
a short masking section
--
Gilles.
__
Jan Kiszka wrote:
> This is an attempt to fix the bugs found in the minor number management:
> - changing the bitmap requires atomic operations
> - clrbits/setbits work against xnarch_atomic_t, and that is only 32 bit
> wide on x86-64
I think we should rather fix xnarch_atomic_t to be the size o
This is an attempt to fix the bugs found in the minor number management:
- changing the bitmap requires atomic operations
- clrbits/setbits work against xnarch_atomic_t, and that is only 32 bit
wide on x86-64
The approach taken here is building the bitmap as an array of
xnarch_atomic_t variables
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> We should indeed postpone this just in case the upper layer indexes the extra
>> state on the minor value. We can also simplify a few things doing so.
>>
>> --- ksrc/nucleus/pipe.c (revision 4565)
>> +++ ksrc/nucleus/pipe.c (working copy)
>> @@
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> We should indeed postpone this just in case the upper layer indexes the
>>> extra
>>> state on the minor value. We can also simplify a few things doing so.
>>>
>>> --- ksrc/nucleus/pipe.c (revision 4565)
>>> +++ ksrc/nucleu
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> We should indeed postpone this just in case the upper layer indexes the extra
>> state on the minor value. We can also simplify a few things doing so.
>>
>> --- ksrc/nucleus/pipe.c (revision 4565)
>> +++ ksrc/nucleus/pipe.c (working copy)
>> @@
Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> We should indeed postpone this just in case the upper layer indexes the
>>> extra
>>> state on the minor value. We can also simplify a few things doing so.
>>>
>>> --- ksrc/nucleus/pipe.c (revision 4565)
>>> +++ ksrc/nucleus/pi
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> We should indeed postpone this just in case the upper layer indexes the extra
>> state on the minor value. We can also simplify a few things doing so.
>>
>> --- ksrc/nucleus/pipe.c (revision 4565)
>> +++ ksrc/nucleus/pipe.c (working copy)
>> @@
Philippe Gerum wrote:
> We should indeed postpone this just in case the upper layer indexes the extra
> state on the minor value. We can also simplify a few things doing so.
>
> --- ksrc/nucleus/pipe.c (revision 4565)
> +++ ksrc/nucleus/pipe.c (working copy)
> @@ -77,11 +77,9 @@
>
>
16 matches
Mail list logo
