Re: [RFC PATCH 0/3] O_TMPFILE and SHM_ANON for the Hurd

[Samuel Thibault]

Hello,

Sergey Bugaev, le lun. 12 déc. 2022 14:46:33 +0300, a ecrit:
> Then, Linux also has memfd_create (), which makes a temp file without touching
> any fs at all. This API is widely used in the Wayland ecosystem as the
> recommended way to create shared memory.  But such an approach would not work
> as-is on the Hurd: in order for there to be an fd, there has to be a server
> somewhere, servicing that fd.

Can't glibc itself serve it?

The drawback is that it'd only keep working while the creator is
running.

> We can't just make an fd out of "pure memory" -- it may be an fd to
> /hurd/tmpfs, but that /hurd/tmpfs needs to exist and be accessible. So
> being usable in an empty chroot is not going to happen anyway, unless
> we start spawning our own instances of /hurd/tmpfs for each memfd,
> which sounds like a terrible idea.

For a really-working memfd, it'd have to be so anyway.

> And so in that light, the FreeBSD alternative to memfd_create () -- namely
> SHM_ANON -- sounds much more approachable to me, while being, well, a bit less
> widely supported in the Wayland ecosystem than memfd, but still quite popular.
> We already implement shm by creating files under /dev/shm/

That has the benefit of factorizing the server part, indeed.

> As for the implementation: basically all of the SHM_ANON implementation, 
> except
> the very definition, ended up in the generic / POSIX version of shm_open () 
> and
> __shm_get_name (), predicated on defined (SHM_ANON) && defined (O_TMPFILE).
> This sounds problematic: while there is indeed nothing Hurd-specific about the
> implementation, and any port that supports O_TMPFILE and wants to support
> SHM_ANON could use these code paths, what if another port wants to implement
> SHM_ANON differently? Should I make a separate copy of shm_open.c in
> sysdeps/mach/hurd instead of modifying the generic version?

I would say that we can afford not foreseeing this, and wait for the
case to happen to see how to refactor things?

Thanks for this! We'll be able to commit things after the 2.37 release.
Samuel