I have been hearing comments that there might be redundancy between dax and memfd - and have recently become aware of the guest_memfd work. A session where we discuss these related abstractions, their use cases, and whether there is redundancy seems like it would be useful. I come at this primarily as the author of famfs [1,2,3,4], which exposes disaggregated shared memory as a scale-out fs-dax file system on devdax memory (with no block backing store. Famfs is currently dependent on a dax instance for each memory device (or each tagged allocation, in the case of cxl DCDs (dynamic-capacity devices). DCDs create a "tag namespace" to memory/devdax devices (and tags are basically UUIDs). Famfs, similar to conventional file systems that live on block devices, uses the device abstraction of devdax to identify and access the backing memory for a file system. Much like block devices generally have recognizable superblocks at offset 0 (see lsblk etc.), sharable memory devices have UUIDs, and may also have superblocks. The device abstraction of tagged memory is a very useful property. I've been asked a number of times whether famfs could live on a memfd, and I currently think the answer is no - but I think we are at a point where these abstractions should be examined and discussed in context. Brief famfs status: At LSFMM '24 the consensus was that it should be ported into fuse. That work is getting close but not quite ready to post patches. Those should start to appear this spring. [1] https://github.com/cxl-micron-reskit/famfs [2] https://lwn.net/Articles/983105/ [3] https://lore.kernel.org/linux-cxl/cover.1708709155.git.john@xxxxxxxxxx/ [4] https://lore.kernel.org/linux-cxl/cover.1714409084.git.john@xxxxxxxxxx/ Cheers, John