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...
Ok, xnpipe_bitmap can remain ulong but a) xnpipe_minor_alloc must use setbits and b) for some reasons clrbits in xnpipe_minor_free does not build on my 64 bit host. Maybe compiler issue. Investigating... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core