+Will On Wed, Aug 10, 2022, David Hildenbrand wrote: > On 10.08.22 11:22, Chao Peng wrote: > > On Fri, Aug 05, 2022 at 03:22:58PM +0200, David Hildenbrand wrote: > >> On 06.07.22 10:20, Chao Peng wrote: > >>> This patch introduces memfile_notifier facility so existing memory file > >>> subsystems (e.g. tmpfs/hugetlbfs) can provide memory pages to allow a > >>> third kernel component to make use of memory bookmarked in the memory > >>> file and gets notified when the pages in the memory file become > >>> invalidated. > >> > >> Stupid question, but why is this called "memfile_notifier" and not > >> "memfd_notifier". We're only dealing with memfd's after all ... which > >> are anonymous files essentially. Or what am I missing? Are there any > >> other plans for fs than plain memfd support that I am not aware of? > > > > There were some discussions on this in v3. > > https://lkml.org/lkml/2021/12/28/484 > > Sean commented it's OK to abstract it from memfd but he also wants the > > kAPI (name) should not bind to memfd to make room for future non-memfd > > usages. > > Sorry, but how is "memfile" any better? memfd abstracted to memfile?! :) FWIW, I don't really like the memfile name either. > I understand Sean's suggestion about abstracting, but if the new name > makes it harder to grasp and there isn't really an alternative to memfd > in sight, I'm not so sure I enjoy the tried abstraction here. ARM's pKVM implementation is potentially (hopefully) going to switch to this API (as a consumer) sooner than later. If they anticipate being able to use memfd, then there's unlikely to be a second backing type any time soon. Quentin, Will? > Otherwise we'd have to get creative now and discuss something like > "file_population_notifer" or "mapping_population_notifer" and I am not > sure that our time is well spent doing so right now. > > ... as this is kernel-internal, we can always adjust the name as we > please later, once we *actually* now what the abstraction should be. > Until then I'd suggest to KIS and soft-glue this to memfd. > > Or am I missing something important? I don't think you're missing anything. I'd still prefer a name that doesn't couple KVM to memfd, but it's not a sticking point, and I've never been able to come up with a better name... With a little bit of cleverness I think we can keep the coupling in KVM to a minimum, which is what I really care about.
