From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=owlfolio.org header.i=@owlfolio.org header.b="H5YWLcXC"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="nKRRZfG4" Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA6BA9F; Wed, 22 Nov 2023 08:18:37 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 639495C025D; Wed, 22 Nov 2023 11:18:34 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Wed, 22 Nov 2023 11:18:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1700669914; x=1700756314; bh=0N 7LnLLSIxjD9++FeLj5Mk+TvcxPDSYsacxSthe5NaA=; b=H5YWLcXCNCxOMWjJ6f RWt5wIlZrc0ZUJrvy7wSUE5gy25wRlMdf0zYCNxEfZJftOyEx9m5HEakp5XCLInG zkesPYLKfpg6IlDay5uz5Fq5LiCvKJvr97Ul/ANsvOotdaYTfvRtsxIq2lPNVqDn K5ZvVcuvfNuRkJYiqpjn+ITBgM/rDrETr8PmG3Taw0e3RE9vib4ddEONipMOp9jr uJO8J6oA/GoxGNVS7I1vyB0qElbx8BjYbQHVngLeGOc77m2Ftu5YHy9g0anWl9Sc I1Ef/sTpsmRBQ60lPpUZR+LGTtp76pihBfpmT2Kvk/3gQim9ddUfyYjqiF53TJjv c8YA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1700669914; x=1700756314; bh=0N7LnLLSIxjD9 ++FeLj5Mk+TvcxPDSYsacxSthe5NaA=; b=nKRRZfG4EH5S6hBLP0zhxB+8BQJRS 6zEeipyIocf97fNuq7jKY0mlFMWHa0wtH6GRNmSyGFJeM3yEbr2AFBnNMT/y6uJ+ drM1yPEyFjUgEA0QUoP2PgMOD4GS3Ax6dSCnSqdKj2/wVY8jI4bPBX+MqALFp0Xk ZeNF6133McjJbWjAxqZTvbAVHhaEV+ACJgrkRscsXoy/DZX41J1aVQhraoj2rhBz dLTSUQSJT7tMqQQyjvCYTZJda8fdgK9se/RemEMl6DHgyzPKoYLWsHNeG7IZza2L wRhdVB8eabXisX23aKKBKcUAJo9ScKWIRUwMP7OAOgglNSa1APaIvZYVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehuddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 24293272007B; Wed, 22 Nov 2023 11:18:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1234-gac66594aae-fm-20231122.001-gac66594a Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <8a21bcea-ba93-4b3c-b99e-bb9f735c5755@app.fastmail.com> In-Reply-To: <698dd63e-9cd8-2d22-c4ca-d8138ed97606@redhat.com> References: <87fs15qvu4.fsf@oldenburg.str.redhat.com> <87leawphcj.fsf@oldenburg.str.redhat.com> <878r6soc13.fsf@oldenburg.str.redhat.com> <15b01137-6ed4-0cd8-4f61-4ee870236639@redhat.com> <6aa721ad-6d62-d1e8-0e65-5ddde61ce281@themaw.net> <698dd63e-9cd8-2d22-c4ca-d8138ed97606@redhat.com> Date: Wed, 22 Nov 2023 11:18:12 -0500 From: "Zack Weinberg" To: "Ian Kent" , "Miklos Szeredi" , "Ian Kent" Cc: "Florian Weimer" , "GNU libc development" , 'linux-man' , "Alejandro Colomar" , "Linux API" , linux-fsdevel@vger.kernel.org, "Karel Zak" , "David Howells" , "Christian Brauner" , "Amir Goldstein" , "Arnd Bergmann" Subject: Re: proposed libc interface and man page for statmount(2) Content-Type: text/plain On Tue, Nov 21, 2023, at 6:28 PM, Ian Kent wrote: > On 22/11/23 04:42, Zack Weinberg wrote: >> On Tue, Nov 21, 2023, at 2:42 PM, Miklos Szeredi wrote: >>> handle = listmount_open(mnt_id, flags); >>> for (;;) { >>> child_id = listmount_next(handle); >>> if (child_id == 0) >>> break; >>> /* do something with child_id */ >>> } >>> listmount_close(handle) >> >> Why can't these be plain old open, read, and close? Starting from a pathname >> in /proc or /sys. Doesn't allow lseek. > > I'm not sure how this would work, there aren't a series of paths in proc > that represent mounts? It would be a new one created for this purpose. listmount_open(mnt_id, flags) == open("/proc/mount_ids", O_RDONLY) + ioctl(fd, LISTMNT_QUERY_ID, mnt_id) + ioctl(fd, LISTMNT_QUERY_FLAGS, flags) and then read(fd, buf, sizeof(buf)) gives you sizeof(buf)/sizeof(mntid_t) mount IDs. Or, if you prefer, keep the new listmount_open() system call but have it return a file descriptor that acts like a pipe filled with all the child mount IDs. The main point of my suggestion is that listmount_next and listmount_close can, and should (IMO), just be read() and close(). Note that I'm _not_ suggesting a text-based interface like most of /proc. What you read is native-endian binary mount IDs. > One is that open() is a fairly high overhead system call and it so it > won't cope well with traversing a large volume of mounts. ... > Second is that, because the mount table lives in a file (actually more > than one with slightly different formats) it needs to be traversed every > time one is looking for a mount which has been shown to be high overhead, Does my clarified explanation address these concerns? zw