As for compatibility with VM_LOCKONFAULT, do we need a new
MADV_GUARD_INSTALL_LOCKED or can we say MADV_GUARD_INSTALL is new enough
that it can be just retrofitted (like you retrofit file backed mappings)?
AFAIU the only risk would be breaking somebody that already relies on a
failure for VM_LOCKONFAULT, and it's unlikely there's such a somebody now.
Hmm yeah I suppose. I guess just to be consistent with the other _LOCKED
variants? (which seem to be... undocumented at least in man pages :P, and yes I
realise this is me semi-volunteering to do that obviously...).
But on the other hand, we could also expand this if you and I see also Dave feel
this makes sense and wouldn't be confusing.
Just my 2 cents: one thing that came to mind: an existing library would
have to be updated to use the _LOCKED variant if the app would be using
mlockall(future), which is a bit unfortunate -- and if it could be
avoided, it would be great.
But yeah, devil is in the detail ...
--
Cheers,
David / dhildenb
