On Mon, May 01, 2000 at 10:43:34AM +0200, Kevin D. Kissell wrote:
> >I'm only worried because I don't know how much software such a change
> >would break.
> But it's already broken - it just doesn't know it. The difference is that
> now the software will fail in a systematic and recoverable way, whereas
> before it would simply be randomly corrupt. I agree that it's regrettable,
> but the job of the OS (IMHO) is to provide a known-reliable access
> to the underlying hardware, and to refuse accesses that compromise
> the integrity of the system and the application.
I think we're about to mix two issues. The one is about fixing a bug,
the other is a design issue is ``Do we want to support coherency between
mmap and read/write of the mapped fd''.
Oh, but that's the easy case. You just say that you don't guarantee cache
coherency between writes and mmap's. Problem solved.
It's actually the right solution. Few other systems guarantee cache
coherency under those circumstances either, so basically no existing
applications depend on it anyway. Certainly not in an embedded space.
> >IRIX uses something they call page ownership switching. Essentially they
> >ensure that only mappings of one colour are accessible at any time.
> >Accessing a page's mapping of a different colour will make the mm flush
> >caches, make the old colour inaccessible and the new colour accessible
> >in the page tables. That requires a reverse mapping of physical to virtual
> >addresses, something that Linus so far has always refused to accept.
> Just what has he refused to accept, and what was his rationale?
He does not want a facility that allows to find all virtual addresses
to which a page is mapped as part of the generic memory managment.
That's actually not a big problem, it can be handled in update_mmu_cache,
that is in machine specific code.