Re: [Xenomai-core] [PATCH v2 2/3] nucleus: Include all heaps in statistics

[Philippe Gerum <rpm@xenomai.org>]

On Tue, 2009-10-20 at 13:44 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2009-10-19 at 21:09 +0200, Jan Kiszka wrote:
> >> Gilles Chanteperdrix wrote:
> >>> Jan Kiszka wrote:
> >>>> @@ -234,12 +239,65 @@ int xnheap_init(xnheap_t *heap,
> >>>>  
> >>>>  	appendq(&heap->extents, &extent->link);
> >>>>  
> >>>> +	vsnprintf(heap->name, sizeof(heap->name), name, args);
> >>>> +
> >>>> +	spin_lock(&heapq_lock);
> >>>> +	appendq(&heapq, &heap->stat_link);
> >>>> +	spin_unlock(&heapq_lock);
> >>> You can not use a Linux spinlock in xnheap_init and xnheap_destroy:
> >>> - this breaks the build for the simulator;
> >>> - callers of xnheap_init and xnheap_destroy are not guaranteed to run on
> >>> the root domain.
> >> Oh, yes, unfortunately. That callers appear to be fixable, but that's
> >> probably not worth it at this point.
> > 
> > There is nothing to fix here. It's part of the service definition to be
> > able to call it from primary mode.
> 
> Strictly spoken not. But given that xnheap_init_mapped does not fulfill
> this promise and that quite a few users have an either-or use of this
> tuple, it doesn't buy us much to allow primary mode.

xnheap_init_mapped is derived from xnheap_init for obvious code reuse
issues, but this does not mean at all that xnheap_init should inherit
the prerequisites of xnheap_init_mapped when it comes to calling
context. Therefore, xnheap_init shall remain callable from primary
context; this is a published API out of tree code may rely on, and there
is absolutely no point in changing its requirements so far.

> 
> Jan
> 
-- 
Philippe.