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/nucleus/pipe.c     (working copy)
>>> @@ -77,11 +77,9 @@
>>>
>>>  static inline void xnpipe_minor_free(int minor)
>>>  {
>>> -   if (minor < 0 || minor >= XNPIPE_NDEVS)
>>> -           return;
>>> -
>>> -   __clrbits(xnpipe_bitmap[minor / BITS_PER_LONG],
>>> -             1UL << (minor % BITS_PER_LONG));
>>> +   /* May be called with nklock free. */
>>> +   clrbits(xnpipe_bitmap[minor / BITS_PER_LONG],
>>> +           1UL << (minor % BITS_PER_LONG));
>> Bad news: This doesn't fly as is. All modifying operations on
>> xnpipe_bitmap must be atomic and xnpipe_bitmap has to be
>> xnarch_atomic_t. But then find_first_zero_bit breaks. Is there some
>> version for atomic arrays? I guess we have to open-code this, at least
>> down to word-level...
>>
> 
> #define clrbits(flags,mask)  xnarch_atomic_clear_mask(&(flags),mask)
> 
> which is either translated to atomic_clear_mask() on x86 which works on a long
> value, or to any Xenomai-local implementation that work the same way for other
> archs. IOW, clrbits() shall be an atomic op by essence in our implementation.
> 
> The thing is that Linux atomic_set/clear_mask() on x86_64 is broken
> (s,andl,andq), so we may have to provide ours.

well, it may be a feature. Maybe they only need atomic ints.

-- 
                                                 Gilles.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to