writable swap cache explained (it's weird)

There are two options:

a) disallow MAP_SHARED mappings of anonymous memory from
/proc/self/mem

b) implement shared anon mappings

(a) sounds like the Obvious Thing To Do in the mmap method for /proc, but will break xdos. Wtf were they thinking in writing that insane code? Hmmm, this bug probably applies to 2.0 too.... in a much more subtle fashion.

As for (b), I'll try to present code by Saturday, as it is a nice feature to add to our cap. =) (No, it's not going to be anything like the awful shm code.)

-ben

--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]

For implementing shared anon mapping, why can't you just mmap a temp file and then unlink it? This should provide the expected capabilities, and the disk image would disappear when the last mapping closes.

Seems like that should work for the xdos case, though it would require a few changes to the code.

Regards,
Bill

--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]

The insane code is indeed insane, but I think I understand why they did
it: they didn't want to mess around with sysv shared memory regions.

I'd love to just completely get rid of mmap() on /proc/self/mem, because it actually is a bad idea completely (not just the shared mappings - even a private mapping of another mapping that is shared has simply completely untenable logical problems).

I'd much more prefer for somebody to take the time to change dosemu to use the standard (and supported) sysv shared memory setup than to make any kernel changes..

Linus

--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]

I think it would be better if they used the new POSIX.4 SHM support (shm_open(3) and friends). To do that, though, the shmfs patch would need to be included in the kernel, though. Yeah, yeah, I know: feature freeze. But when has that ever stopped you? ;-)

				Regards,

					Richard....

--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]

Good guess but no. Dosemu already uses sysv shared memory regions where it can. But for some applications it needs page level control, and sysv doesn't give you that.

Further the dosemu history states that when it was attempted to map a temporary file, and use the standard mmap functionality that way, the performance became unacceptable on nfs filesystems.

So /proc/self/mem was the only solution open to dosemu, that provided the required level of performance and control.

I agree and this is why I have put a considerable amount of effort into implementing a posix shared memory interface.

Eric

--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]