From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by sourceware.org (Postfix) with ESMTPS id 760FD3858D37 for ; Thu, 20 Apr 2023 21:47:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 760FD3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-541f4ee6f89so472295eaf.2 for ; Thu, 20 Apr 2023 14:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682027275; x=1684619275; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SqQeM6CkNFUOwo4xMoTYPbkt2cp9385mkIdD8NqJxj8=; b=qn521coqGYsir5eqfrAbRWCCwmBmuitneSmfLuHnfsPrEXU53vUY/rVFLh2Y37S2il /4Q/69UyMjAa5qxjrAy2uPNq0nsT+kJTYVXq/mgErMOehtbf9ttBEC4byQ9tCnZUV5YI Ye+GU032gM8A240A2R977ScuMthzy5tgzgc3ZNsicVBcCNzaMegq8EB92/hY3dQZlEo0 LxYmGc6pRBogponw2/AX/w6HXga2HinVapt/UzBPI+3DOVKWnXnhlzvSx+vcZysSTzG+ NODZZXsvWg+4YbujP4bapT+ZHW4d5WW/WQ0Tvri40acDzfZUVypNHkjfmZ5/hVfG7m7y BBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682027275; x=1684619275; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SqQeM6CkNFUOwo4xMoTYPbkt2cp9385mkIdD8NqJxj8=; b=F8C35LP+/t2a3P//xQHF9wRprTezKEuEi+NsFxx7Ioq4Fv+nhq1TfjHFACG1OVmx27 heWQUt/ka6ysPZh+kC6UkSKddFt/s43iohqrnuqMR1VGeciSjSofL/2LypLfz4GmAfdJ SB5g5QvmDSNAGkLVZQUBNWUGC9vLyDfo4OIgEHc4M7cWGvEb7bOtibeGgA72jD7taBo6 JtfC2VQ30XqjHMJb8ady7lzEgr/fP2c4dX6C6ptFqOaXPpskgEf4jLaS7Z/Zy8l6ozfN utIK/sULNZefKwv21NTKjk/4Jv5s0ALkPGgKGBvD4LcQWZDLxUcwB0wZKR5okj1CRZC7 d3kQ== X-Gm-Message-State: AAQBX9f3GhOcQJkMtqqbcxDc6iVlAXoKrXGzLrzHrvUbgYNQdifodC5l 6a6qNECnGCzZOvqLnKkvwDHksVeOvMJpYHUvMoU= X-Google-Smtp-Source: AKy350YaomEqn8iMvQ3V++EVDkNc+/uOR7E+Dx0wai4Gv52GNByy9r2ZUrK2nSYHLCpOenNNCjiYmOnC4rIVzR7fz/g= X-Received: by 2002:a05:6870:73ce:b0:184:5f08:a130 with SMTP id a14-20020a05687073ce00b001845f08a130mr1561472oan.33.1682027274693; Thu, 20 Apr 2023 14:47:54 -0700 (PDT) MIME-Version: 1.0 References: <20230417133902.99040-1-bugaevc@gmail.com> <20230420211405.i7uwo3ocpjudfx45@begin> In-Reply-To: <20230420211405.i7uwo3ocpjudfx45@begin> From: Sergey Bugaev Date: Fri, 21 Apr 2023 00:47:43 +0300 Message-ID: Subject: Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA To: Samuel Thibault Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org, Emilio Pozuelo Monfort Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Apr 21, 2023 at 12:14=E2=80=AFAM Samuel Thibault 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] =3D 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