> On Oct 23, 2014, at 09:38 , Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > >>> What do you mean with "return errors"? Should this be a fatal error or >>> a >>> linker error? >> >> Let's take the simplest case. A CPU with no cache control. Empty stubs is >> the right implementation. >> >> Next up is just enable, disable and flush. Can we map those to more >> specialized methods. Is it ok and expected that disable data cache does all? >> Or flush flushes all. > > What is the use case for a cache disable/enable at application level? Most > cache disable functions in the tree are broken. > > The only useful cache manager functions I see is data cache flush/invalidate > lines and instruction cache invalidate lines. > >
My original thinking about "return errors" is to return an error code when an unimplemented function is called, because somebody called that function for what they thought was a good reason. A link-time warning (not error) if the function is linked-in to the user application would be great, I don't know if that is possible. That approach moves the warning from the BSP compilation stage to the conscious usage of an unusual unimplemented function by a BSP user. I don't know what the use cases of all those cache manager functions are. The few real-world unusual cache usages that I can think of are chip and application specific (e.g. reserve a section of cache as a section to store some critical code in) and I wouldn't even attempt to generalize them for use in a "manager". My desirements would be, in order and if possible: - Link time warning when an unimplemented function is called from an application; - Run-time error return (not fatal abort type thing, but something the application should handle) when an unimplemented function is called; - Nothing at all. Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
