Messages in this thread | | | Date | Mon, 17 Apr 2023 17:11:39 +0000 | Subject | Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) | From | Ackerley Tng <> |
| |
Sean Christopherson <seanjc@google.com> writes:
> On Mon, Apr 17, 2023, David Hildenbrand wrote: >> On 17.04.23 17:40, Sean Christopherson wrote: >> > I want to start referring to the code/patches by its >> syscall/implementation name >> > instead of "UPM", as "UPM" is (a) very KVM centric, (b) refers to the >> broader effort >> > and not just the non-KVM code, and (c) will likely be confusing for >> future reviewers >> > since there's nothing in the code that mentions "UPM" in any way. >> > >> > But typing out restrictedmem is quite tedious, and git grep shows >> that "rmem" is >> > already used to refer to "reserved memory". >> > >> > Renaming the syscall to "guardedmem"...
>> restrictedmem, guardedmem, ... all fairly "suboptimal" if you'd ask >> me ...
> I'm definitely open to other suggestions, but I suspect it's going to be > difficult > to be more precise than something like "guarded".
> E.g. we discussed "unmappable" at one point, but the memory can still be > mapped, > just not via mmap(). And it's not just about mappings, e.g. read() and > its many > variants are all disallowed too, despite the kernel direct map still > being live > (modulo SNP requirements).
I'm for renaming the concept because restrictedmem is quite a mouthful. :)
How about "concealedmem" or "obscuredmem" to highlight the idea of this memory being hidden/unreadable/unmappable from userspace?
Guarded is better than restricted but doesn't really highlight how/in what way it is being guarded.
| |