why gets "invalidate_cache" a const void ptr?

[Gedare Bloom]

P.S. I don't think there is any correctness issue here, just how the
programmer understands the semantics of the function call to
invalidate the cache.

-Gedare

On Fri, Apr 9, 2010 at 2:44 PM, Gedare Bloom <gedare at gwmail.gwu.edu> wrote:
> 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.
>>
>