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?! :) 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. 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? -- Thanks, David / dhildenb
