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, DKIM_VALID_AU,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-ob0.topicbox.com (tb-ob0.topicbox.com [64.147.108.117]) by inbox.vuxu.org (Postfix) with ESMTP id 97C7820D6F for ; Sun, 7 Apr 2024 17:00:28 +0200 (CEST) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 413602D62E for ; Sun, 7 Apr 2024 11:00:27 -0400 (EDT) (envelope-from bounce.mM124c4e12c40240ab85dbdea0.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 3CFC41475830; Sun, 7 Apr 2024 11:00:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:from:list-unsubscribe; s= dkim-1; t=1712502027; x=1712588427; bh=iuSItRbJkSDocqrBw/4SAnqqf 1RGre2s58sVy5XsW1I=; b=W30DiURqMK20rboUb/NzNZExdG/OWFIEBktfqkC7z gUhKpsVy8yKHwogP7xj4MmQYL0rR74iTyvwvx3Ya58i9WNRoGNg2h3TnQQ+p/gKN mx6iF+ydbp5oNheirLsb8sx8Fx8VFxtlttfucGvzMEH8QlfUT25AdyhoTFE6L+ny f8= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] openat() Message-Id: <17125020190.Dfc7b.875375@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> <17124367090.cDf02.77195@composer.9fans.topicbox.com> <17124538090.BD80ABf5D.12467@composer.9fans.topicbox.com> In-Reply-To: <17124538090.BD80ABf5D.12467@composer.9fans.topicbox.com> Date: Sun, 7 Apr 2024 11:00:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17125020191.BEeE95fa9.875375 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 8d23a93a-f4ef-11ee-92d9-20772b2d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NMTI0YzRlMTJjNDAyNDBhYjg1ZGJk?= =?UTF-8?B?ZWEwPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> From: "Alyssa M via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M124c4e12c40240ab85dbdea0:1:4AlGkjj7LyTW4tEGoQ2AyX7kToB7awi0lhg10NE3JS4 --17125020191.BEeE95fa9.875375 Date: Sun, 7 Apr 2024 11:00:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I left the oven on for my partly-baked idea. I'm now thinking that with fd 5 as an example: =C2=A0open ("#d/5dir/a/b/c", ...) might be a practical way to do this (the=C2=A0 syntax I suggested earlier w= ould require walking from a file, which wouldn't be sensible). So I went snorkeling in the kernel to see how hard this would be... devdup.c uses the bottom bit of the qid.path to distinguish #d/0 from #d/0c= tl, so that would have to change to modulo 3 to allow the '5dir' virtual di= rectory to be found when qid.path % 3 =3D=3D 2, and twicefd would have to c= hange to thricefd. The idea is that a walk to #d/5dir would continue the walk at the cloned un= opened directory fid that fd 5 is also holding in its chan (as I suggested = in a previous post). Currently, dupwalk just calls devwalk in dev.c, so we'd probably want to do= the first step in dupwalk, doing fd2chan, much like dupopen does. Then cal= l something else to walk from there. I'm not sure what though: walk() maybe? I don't really know my way around the Plan 9 kernel, so this may not be the= right way to do this. There are some scary creatures in dev.c, including a= spikey backward pointing goto and some dark comments about contradictory r= ules and ugly bits... :o You'd want to get the effect of having the directory open on fd 5 bound to = #d/5dir without actually doing the bind (because you can't...). Ideally if fd 5 is not a directory, then #d/5dir should not even appear. The idea is that then: int openat (int fd, char *path, int mode) { char newpath[PATHSIZE]; sprintf (newpath, "#d/%ddir/%s", fd, path); return open (newpath, mode); } could be a function in a library somewhere that would parcel it up in a mor= e convenient form, and the rest of the *at suite could follow the same patt= ern. Maybe someone would want this for a version of APE emulating Linux? So the idea is still partly-baked, and still very much in the realm of the = hypothetical:=20 Ron Minnich wrote: "I don't want this to turn into a debate on the merits of openat" I'm approaching this in the spirit of "if we had to implement this, how wou= ld we do it while inflicting the least harm"... :) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M124c4= e12c40240ab85dbdea0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17125020191.BEeE95fa9.875375 Date: Sun, 7 Apr 2024 11:00:19 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I left the oven on for my partly-baked idea.

I'm now thinking that with fd 5 as an e= xample:
 open ("#d/5dir/a/b/c", ...)
might be a practical way to do this (the  syntax I suggested = earlier would require walking from a file, which wouldn't be sensible).=

So I went snorkeling in the kernel to see= how hard this would be...

devdup.c uses t= he bottom bit of the qid.path to distinguish #d/0 from #d/0ctl, so that wou= ld have to change to modulo 3 to allow the '5dir' virtual directory= to be found when qid.path % 3 =3D=3D 2, and twicefd would have to change t= o thricefd.
The idea is that a walk to #d/5dir would contin= ue the walk at the cloned unopened directory fid that fd 5 is also holding = in its chan (as I suggested in a previous post).

Currently, dupwalk just calls devwalk in dev.c, so we'd probably= want to do the first step in dupwalk, doing fd2chan, much like dupopen doe= s. Then call something else to walk from there. I'm not sure what thoug= h: walk() maybe?
I don't really know my way around the = Plan 9 kernel, so this may not be the right way to do this. There are some = scary creatures in dev.c, including a spikey backward pointing goto and som= e dark comments about contradictory rules and ugly bits... :o

You'd want to get the effect of having the director= y open on fd 5 bound to #d/5dir without actually doing the bind (because yo= u can't...).
Ideally if fd 5 is not a directory, then #= d/5dir should not even appear.

The idea is= that then:
int
openat (int fd, char *path, int mode)
{
	char newpath[PATHSIZE];
	sprintf (newpath, "#d/%ddir/%s", fd, path);
	return open (newpath, mode);
}

could be a function in a library somewhe= re that would parcel it up in a more convenient form, and the rest of the *= at suite could follow the same pattern. Maybe someone would want this for a= version of APE emulating Linux?

So the id= ea is still partly-baked, and still very much in the realm of the hypotheti= cal:

Ron Minnich wrote:
&= quot;I don't want this to turn into a debate on the merits of openat&qu= ot;

I'm approaching this in the spirit= of "if we had to implement this, how would we do it while inflicting = the least harm"... :)
= --17125020191.BEeE95fa9.875375--