Re: [Xenomai-core] Pending patches

[Philippe Gerum <rpm@xenomai.org>]

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.

> Jan
> 


-- 
Philippe.