[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sergey Bugaev
Subject: Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA
Date: Fri, 21 Apr 2023 00:47:43 +0300

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]