On 23/10/14 15:16, Joel Sherrill wrote:
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault<dufa...@hda.com>
wrote:
On Oct 20, 2014, at 16:47 , Joel
Sherrill<joel.sherr...@oarcorp.com> wrote:
However, should unimplemented versions return an error instead
of being
a NOP? That would force one to visit code that makes
assumptions.
If this is OK for the mpc55xx, feel free to submit a patch
turning the warning off for it.
I tend to agree that if I had a generic drive that wanted to
flush data cache and all we can do on a target is flush all, then
that's preferable to flushing nothing.
If these are called from a cache test then we would end up with a
hard error instead of a warning in that test which makes the issue
worse.
I'm flat-out, I can't do a proper job on this. I couldn't have
told you that the MPC55XX had a unified cache before I checked this
morning, but I would have gotten the answer correct on a
multiple-choice question.
I think that unimplemented operations should return errors and not
OK, forcing one to add an implementation when it is OK. But the
MPC55XX and its cache works fine as long as you keep cache-flushing in
mind and flush it when you should, so I don't recommend anything be
changed in the next RTEMS release.
+1
What we should do is make sure any generic cache mgr functions that
get called within RTEMS are all implemented (I recall there being
some, they may be in score/cpu code though.) Then make the
unimplemented calls be errors. If someone uses it without checking,
they should get slapped for it.
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 thinking is that there are probably tiers of cache capabilities and if we
can define expected behavior of higher tier operations onto lower capability
CPU models, then we have a good solution.
I don't like any errors in this case because as Peter says the code works well
enough for applications as is if it is being used. Injecting a fatal error
would be breakage. Returning an error would (I think) take an API change which
no code would look at.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
