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