why gets "invalidate_cache" a const void ptr?

[Gedare Bloom]

On Fri, Apr 9, 2010 at 2:34 PM, Thomas Dörfler
<Thomas.Doerfler at embedded-brains.de> wrote:
> Hi,
>
>>> I am having trouble seeing where this case would happen.  Why would
>>> you have a system which cached some memory knowing that the
>>> memory and cache would be inconsistent?
>>>
>> The sparc (and sparc64) port deals with this, when it registers a trap
>> (interrupt) handler, it replaces the entry in the trap table going
>> through the data cache, and needs to make sure to invalidate the
>> instruction cache, because the instructions for the old handler might
>> exist.
>>
>> -Gedare
>>
>
> Right. And you pass a pointer to the "invalidate" function, it promises
> you (through the "const" keyword) that it will NOT modify the passed in
> object, but, at least from a CPU point of view, the memory area will
> look different after the call.
>
> That is exactly what I find illogical/wrong.
>
I see your complaint: from the caller's point-of-view, the memory
returned by accessing the pointer to const passed as an argument might
be altered across the function call, although the memory itself didn't
change, the cache was out-of-date.  However, the function does not
actually write to the memory -- the memory was written before by
something else, perhaps DMA or d/i cache mismatch.  I'm not sure
whether it is better to elide the const modifier or not, but it does
let the compiler ensure that the invalidate function does not attempt
to write to the memory location, which is certainly what is expected.
Is "volatile const void*" acceptable to the compiler and does that
make any more sense?

Any one have opinions?
-Gedare
> Thomas.
>