Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA

[Sergey Bugaev <bugaevc@gmail.com>]

On Fri, Apr 21, 2023 at 12:14 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> Sergey Bugaev, le lun. 17 avril 2023 16:38:59 +0300, a ecrit:
> > The only valid flag defined here is FD_CLOEXEC. It is of no concern to
> > the receiving process whether or not the sender process wants to close
> > its copy of sent file descriptor upon exec,
>
> Ok, but couldn't there be some flags that we could want to transfer, in
> the future?

Unlikely -- it's been years (I don't know how old FD_CLOEXEC is
exactly, but it surely predates O_CLOEXEC by many years) and AFAIK
nobody came up with any ideas for more fd flags, other than
FD_CLOFORK, but that wouldn't be transferable either.

And the whole idea of fd flags (as opposed to flags applied to the
open file itself, the peropen in Hurd terms, like O_NONBLOCK and
O_ASYNC) is that they apply to that single file descriptor, and are
not carried over when it's dup'ed. sendmsg+recvmsg is like a remote
dup in this sense.

> I'd better keep the infrastructure, even if it is not
> actually useful for now. So that people who end up needing something see
> that passing it is already supported.

I understand, but also it's not like there's a lot of infrastructure
that I'm removing here. You could think of it that way: the
infrastructure for passing an integer value along with the port is
still there, but currently no valid flags for it are defined, and so 0
is always used. We could spell it as

fds[i] = descriptor->flags & ~FD_CLOEXEC;

if you would prefer; but that would still always evaluate to 0 (but
the compiler wouldn't be aware and would generate the extra
instructions).

Sergey