From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob21.topicbox.com (tb-ob21.topicbox.com [173.228.157.67]) by inbox.vuxu.org (Postfix) with ESMTP id 0BA4322010 for ; Sat, 6 Apr 2024 22:51:58 +0200 (CEST) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob21.topicbox.com (Postfix) with ESMTP id 9331E256AB for ; Sat, 6 Apr 2024 16:51:56 -0400 (EDT) (envelope-from bounce.mM3c21a5ee93f83ca1650b537c.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 43BB9126DBE6; Sat, 6 Apr 2024 16:51:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=from:to :subject:message-id:in-reply-to:references:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:list-unsubscribe; s=dkim-1; t=1712436716; x=1712523116; bh=JGFwMIWATyl1+E6S8E/A13X6Het5A5r+ Y7xvbDzEbXk=; b=py06Z+46iumdRDwX066OqYS/kSxhMnPxPt6ssRxt/SKgM8ic xeLq7qEKlVuRZmSayndV2EMBGYGfwDZMU+N2vdPz5bCEzeuAEb0I5/y6IbPXi36C nkQVWIZ7RklvRc+CBjq4pses0iL3xJp2EHUWZ4Zzhb+IThcOVUh6/HzKOqk= From: moody@posixcafe.org To: 9fans <9fans@9fans.net> Subject: Re: [9fans] openat() Message-Id: <17124367090.cDf02.77195@composer.9fans.topicbox.com> In-Reply-To: <17124314640.ceA1.70581@composer.9fans.topicbox.com> References: <17123537830.EbFe44.28920@composer.9fans.topicbox.com> <17123735270.469FFd7.853634@composer.9fans.topicbox.com> <17124314640.ceA1.70581@composer.9fans.topicbox.com> Date: Sat, 6 Apr 2024 16:51:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17124367091.2E7f61Df9.77195 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 7d789204-f457-11ee-bf32-876641decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NM2MyMWE1ZWU5M2Y4M2NhMTY1MGI1?= =?UTF-8?B?MzdjPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M3c21a5ee93f83ca1650b537c:1:b_CHteibj-Skt26sGc5cfbD10QDg6QMAnkoPyAe4_ac --17124367091.2E7f61Df9.77195 Date: Sat, 6 Apr 2024 16:51:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In response to Ron's mail. Still can not reply from my mail server. I still don't quite understand what you are getting at. I was focusing up on the linux interface (ie openat(int fd, char *path, int= flags, ...)) mapping of open fd to path. I see now as well that openat spe= cifies that the argument must be a fd to a directory , so the issue of walk= not being able to use files is not relevant, but you still have the other = walk(5) limitations on the source fid. If you are instead just wanting something that has the interface of: openat= (char *dir, char *file, mode) for the purpose of avoiding just the cd than = open as you say. Than I don't see why you couldn't usually just combine the= open path yourself before handing it to the kernel. If we put aside the interface and just focus on it's ability to act as a me= thod to cache a walk for reuse with multiple subsequent open's let's say th= an I still think the design of 9p gets in the way. The difference between w= alking first then being able to reuse the fid for further walks, and just a= lways walking from the root is however many path elements being walked inte= rnally to the 9p server. So I imagine that the overhead of doing this parti= al walk first, pinging to the 9p server and back to userspace would only be= cheaper if you were opening quite a large amount of files. Is that what yo= u were getting at Ron? In response to Bakul: I don't think it's just an easy win at all. As mentioned already the act of= getting whatever handle you choose from the 9p server and back to userspac= e as a method of reuse to prevent a couple of internal walks within the 9p = server I think are not going to be favorable in performance. Thanks, moody ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c21a= 5ee93f83ca1650b537c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17124367091.2E7f61Df9.77195 Date: Sat, 6 Apr 2024 16:51:49 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In response to Ron's mail. Still can not r= eply from my mail server.

I still don't qu=
ite understand what you are getting at.

I was focusing up on the linux interface (ie openat(int fd, char *path, int=
 flags, ...)) mapping of open fd to path. I see now as well that openat spe=
cifies that the argument must be a fd to a directory , so the issue of walk=
 not being able to use files is not relevant, but you still have the other =
walk(5) limitations on the source fid.

If you are instead just wanting something that has the interface of: openat=
(char *dir, char *file, mode) for the purpose of avoiding just the cd than =
open as you say. Than I don't see why you couldn't usually just com=
bine the open path yourself before handing it to the kernel.

If we put aside the interface and just focus on it's ability to act as =
a method to cache a walk for reuse with multiple subsequent open's let&=
#39;s say than I still think the design of 9p gets in the way. The differen=
ce between walking first then being able to reuse the fid for further walks=
, and just always walking from the root is however many path elements being=
 walked internally to the 9p server. So I imagine that the overhead of doin=
g this partial walk first, pinging to the 9p server and back to userspace w=
ould only be cheaper if you were opening quite a large amount of files. Is =
that what you were getting at Ron?

I= n response to Bakul:

= 
I don't think it's just an e=
asy win at all. As mentioned already the act of getting whatever handle you=
 choose from the 9p server and back to userspace as a method of reuse to pr=
event a couple of internal walks within the 9p server I think are not going=
 to be favorable in performance.

Thanks,
moody

= --17124367091.2E7f61Df9.77195--