[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: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?

 > > > This is the case for all modern PowerPC systems. It is the
 responsibility of the BSP to provide a cache coherent memory pool if it is
 needed.
 > >
 > > If a BSP has a specific ability to do this then why not provide some
 memory from the malloc heap to the cache coherent allocator?
 >
 > The BSP doesn't know how much memory it needs to allocate from malloc
 for this memory.

 Yes the `motorola_powerpc` has the same issue so nothing different here
 either. And I see it as being no different to other system level sizes we
 are forced to set.

 > > I see not doing this as a bug in those BSPs that needs to be fixed. I
 do not agree with hiding something like this in a call as it currently is.
 A call in a BSP makes it easy to determine the intended mode of operation.
 > >
 > > I hope you understand that have I tripped over this and I will not be
 the last. Generating an error makes it easy to see you need to sort this
 issue out in a BSP.
 > This is understandable. From my point of view this is a documentation
 issue. Maybe we need a BSP checklist, e.g. if your system has no cache/DMA
 coherent memory, then make sure the cache coherent memory allocator is set
 up.

 The fundamental issue is the name of the function does not match what is
 does and it is inconsistent in terms of an API function. I expect a
 specially named allocator to do what it says or fail without making any
 assumptions.

 I would accept the call being
 `rtems_cache_coherent_allocate_if_set_up_else_just_memory()` but I think
 it is too long. :)

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