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-ob20.topicbox.com (tb-ob20.topicbox.com [173.228.157.66]) by inbox.vuxu.org (Postfix) with ESMTP id D2FFD25B39 for ; Fri, 5 Apr 2024 23:49:50 +0200 (CEST) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob20.topicbox.com (Postfix) with ESMTP id 2912F2FF4E for ; Fri, 5 Apr 2024 17:49:49 -0400 (EDT) (envelope-from bounce.mM77db5ff0993c7da831142e92.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id CE66E125B7DC; Fri, 5 Apr 2024 17:49:48 -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=1712353788; x=1712440188; bh=vh1yur9gb/IoaLpTt6xwpAGON tr4nGiqWZAojhJS80c=; b=GxU0PTQyLAPbQAo4x14Bfp6+AKju5Z8dhAOmIeXwQ nCwkwOB9ku/bbfmO9MD225/CJBdTRJRL6HGD3ICd0rFtk8tglD5sBtvFPrZ5jzb5 DeIMWj6NLymHRBRy94nnbIyG5VauCYcigPu/GEQJZU7uu7QSF55WQclTjN7oz9zV Fg= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] openat() Message-Id: <17123537830.EbFe44.28920@composer.9fans.topicbox.com> References: In-Reply-To: Date: Fri, 5 Apr 2024 17:49:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17123537831.410C9c.28920 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 69aa0a76-f396-11ee-aecb-876641decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NNzdkYjVmZjA5OTNjN2RhODMxMTQy?= =?UTF-8?B?ZTkyPg==?= 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:M77db5ff0993c7da831142e92:1:VgrH-x36bYr8jt0Nb2jrPcX5-KcKeE0uRLGPBtkVb_k --17123537831.410C9c.28920 Date: Fri, 5 Apr 2024 17:49:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are you thinking narrowly about "What changes to the Plan 9 kernel would yo= u make to emulate the Linux openat() system call" or more generally about "= How would you design a facility for plan 9 that provides an equivalent serv= ice? As I understand it from the rationale section on the linux man page, the ca= ll exists to avoid a race condition between checking that a directory exist= s and doing something to a path containing it. An additional motivator is p= roviding the effect of additional current working directories notably for L= inux threads (which presumably don't have their own. I think 'threads'=C2= =A0 (processes that share memory) on Plan 9 do???). This is all based on the assumption that holding a file/directory open keep= s it alive and in existence... which on Plan 9, I think it doesn't, does it= ? As I understand it, remove can remove a file or directory that is open, w= hich is not like UNIX/Linux... Sorry, I'm just trying to understand the question. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M77db5= ff0993c7da831142e92 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17123537831.410C9c.28920 Date: Fri, 5 Apr 2024 17:49:43 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are you thinking narrowly about "What cha= nges to the Plan 9 kernel would you make to emulate the Linux openat() syst= em call" or more generally about "How would you design a facility= for plan 9 that provides an equivalent service?

As I understand it from the rationale section on the linux man page,= the call exists to avoid a race condition between checking that a director= y exists and doing something to a path containing it. An additional motivat= or is providing the effect of additional current working directories notabl= y for Linux threads (which presumably don't have their own. I think = 9;threads'  (processes that share memory) on Plan 9 do???).
<= /div>

This is all based on the assumption that holding= a file/directory open keeps it alive and in existence... which on Plan 9, = I think it doesn't, does it? As I understand it, remove can remove a fi= le or directory that is open, which is not like UNIX/Linux...

Sorry, I'm just trying to understand the question.<= br />


= --17123537831.410C9c.28920--