From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id DAD4D3858D35 for ; Sun, 29 Jan 2023 23:31:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DAD4D3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMH9D-00089e-4P; Sun, 29 Jan 2023 18:31:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=Cx4FljSyuUwP3dokdh4wiLCo6QZy6w3z6x7e5lO6vqY=; b=LDr0vE06gDPTDx3y7i4e KC5FTubUJG9dghpN389tzojqwg2dKYu0NdbqHjjFT++At7T+tfQ/eOxiUI08Fcvl1D0GZ49FKW0Dk EvoPpyx1N4i0FsYhb4HuRR/2GnhtsfSqnR98BbVHoUCKwjIVL1AIcWBcD3ZCUdaecaCYw3oYmw2yX e/Pp/5teqOdSvXAw1epcOGBQ6LQulXcs+mjX7ADnJVU3FJTmuJ3lONO3daaqTA4Bh2mP/iY2lYinP ZGJGtLsmmKV60vbkPP7NFRjLJVRbMjr5Cpas7sC99LhTE1qRHhralBDfesfFOm/yUevV74m8AcGeB StO2qitCTQ1lNg==; Received: from lfbn-bor-1-1163-184.w92-158.abo.wanadoo.fr ([92.158.138.184] helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMH9C-0001AU-Ky; Sun, 29 Jan 2023 18:31:42 -0500 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pMH9A-0012op-29; Mon, 30 Jan 2023 00:31:40 +0100 Date: Mon, 30 Jan 2023 00:31:40 +0100 From: Samuel Thibault To: Sergey Bugaev Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org Subject: Re: [RFC PATCH 0/3] O_TMPFILE and SHM_ANON for the Hurd Message-ID: <20230129233140.tkgoqp45u7lrl65u@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org References: <20221212114636.74222-1-bugaevc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221212114636.74222-1-bugaevc@gmail.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP 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: 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