[RTEMS Project] #4243: rtems_cache_coherent_allocate fallback is to return heap memory

[RTEMS trac]

#4243: rtems_cache_coherent_allocate fallback is to return heap memory
-------------------------+---------------------
 Reporter:  Chris Johns  |       Owner:  (none)
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:  6.1
Component:  lib          |     Version:  6
 Severity:  normal       |  Resolution:
 Keywords:               |  Blocked By:
 Blocking:               |
-------------------------+---------------------

Comment (by Chris Johns):

 Replying to [comment:7 Sebastian Huber]:
 > Replying to [comment:5 Chris Johns]:
 > > Replying to [comment:4 Sebastian Huber]:
 > > > Replying to [comment:3 Chris Johns]:
 > > > > Replying to [comment:2 Sebastian Huber]:
 > > > > > The fall back is correct for systems in which all memory is
 cache coherent also for DMA.
 > > > >
 > > > > It is not correct for a call of this type to make **any**
 assumption other than returning memory from the pool it has been given.
 > > >
 > > > It is the responsibility of the BSP to set up this allocator.
 > >
 > > Agreed, so ....
 > >
 > > > There are a couple of BSP for which this fall back is absolutely the
 right thing to do.
 > >
 > > ... why not have those couple of BSPs take responsibility like all
 other BSPs and set up the allocator?
 >
 > The function to simply use the heap on systems where this makes sense
 should be preserved.

 It appears to me this is a convenience for a niche set of BSPs. Over the
 life of RTEMS I have found special case like this at best provide
 surprises and at worst make long term maintenance harder. For example as
 the "special" case BSPs age the ability to make changes and test becomes
 harder and in the end we cannot remove this special case if we wanted too.

 The rational is simple, make the call do just what the name suggests it
 does and make it consistent. The call is to provide cache coherent memory
 and to fail if there is none. Having it assume a default mode may work for
 some but fails for others. My key point is the failure for some is more
 important than the convenience of others.

 > If you want an explicit initialization for this case, then please add
 it.

 I will be providing a patch in time to remove the malloc heap fall back.
 However I do not have or know the list of BSPs where malloc heap memory is
 OK so I cannot updated them. That alone should signal concern about this
 call.

 If you have another solution in mind that meets the requirements I have
 stated I suggest you post a patch. As you say a call to force the
 allocator would be simple and one I consider as OK. I consider it OK
 because a simple grep lets me find which BSPs can support this. Everyone
 else fails until they are updated, something I am happy to see happen.

--
Ticket URL: <http://devel.rtems.org/ticket/4243#comment:8>
RTEMS Project <http://www.rtems.org/>
RTEMS Project