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.
-Gedare > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
