12:19 a.m.
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.
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".
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.
--
Sincerely yours,
Mike.