Am 14.02.2021 um 10:20 schrieb Mike Rapoport rppt@kernel.org:
On Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote:
On 12.02.21 00:09, Mike Rapoport wrote: On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
On 11.02.21 12:27, Mike Rapoport wrote:
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
So let's talk about the main user-visible differences to other memfd files (especially, other purely virtual files like hugetlbfs). With secretmem:
- File content can only be read/written via memory mappings.
- File content cannot be swapped out.
I think there are still valid ways to modify file content using syscalls: e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just fine.
These work perfectly with any file, so maybe we should have added memfd_create as a flag to open(2) back then and now the secretmem file descriptors?
I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently.
Also, open() might open existing files - memfd always creates new files.
Yes, but still open() returns a handle to a file and memfd_create() returns a handle to a file. The differences may be well hidden by e.g. O_MEMORY and than features unique to memfd files will have their set of O_SOMETHING flags.
Let‘s agree to disagree.
It's the same logic that says "we already have an interface that's close enough and it's fine to add a bunch of new flags there".
No, not quite. But let‘s agree to disagree.
And here we come to the question "what are the differences that justify a new system call?" and the answer to this is very subjective. And as such we can continue bikeshedding forever.
I think this fits into the existing memfd_create() syscall just fine, and I heard no compelling argument why it shouldn‘t. That‘s all I can say.