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.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=no 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 E630D2380B for ; Wed, 10 Apr 2024 14:17:52 +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 A3DC9329DB for ; Wed, 10 Apr 2024 08:17:50 -0400 (EDT) (envelope-from bounce.mM6778010ee676c3e2eca3101e.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 51DA912DEB0F; Wed, 10 Apr 2024 08:17:50 -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=1712751470; x=1712837870; bh=2D8ix9fAMBtp/XaRJj4wg0pT3ST67JSN aXsFVJyt9SY=; b=ZgLF7x9RyjPOQNnGwVasknC8rhkOi4f7SNFih0RqeK77b0sZ VTX+qWzHTHTDgKmvy2GvGmRDiB0c0JzPhZk32AB1fnHzR1VOZEy//7zE1te3vMcO T1zIgo352ZCFhBpEWC/3labAEkibBCM6A+tSq5Gai8PSIJrU/31r08jJxQs= From: wb.kloke@gmail.com To: 9fans <9fans@9fans.net> Subject: Re: [9fans] openat() Message-Id: <17127514630.D9179.55872@composer.9fans.topicbox.com> In-Reply-To: <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> <17125020190.Dfc7b.875375@composer.9fans.topicbox.com> Date: Wed, 10 Apr 2024 08:17:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17127514640.39bc18b3a.55872 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 55c6f6a8-f734-11ee-a1b9-876641decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NNjc3ODAxMGVlNjc2YzNlMmVjYTMx?= =?UTF-8?B?MDFlPg==?= 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:M6778010ee676c3e2eca3101e:1:L2m-CymQWRhH6jjPucxAZJL-pC5aVbsc3ajsdN1fV84 --17127514640.39bc18b3a.55872 Date: Wed, 10 Apr 2024 08:17:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some replies seem to hold openat() for superfluous. In fact, IMHO the tradi= tional syscall open() should be deprecated. In FreeBSD at least, the libc=C2=A0 open() does in fact use the real thing = __sys_openat(). in /usr/src/lib/libc/sys/open.c via the interposing table. Some days ago, I experimented with a user space implementation of the of th= e file lookup in namei() to get the benefits of a=C2=A0 proc specific names= pace on my FreeBSDsystem, making Plan9 style bind and mount=C2=A0 available= . This involved changing every=C2=A0 slash in a path name into=C2=A0 openat= () calls for the splltted path components.=C2=A0pkeus.de/~wb/ns.c Btw, there is another syscall in FreeBSD, which overlaps open() and openat(= ) , namely fhopen(). This seems to isolate the namespace lookup operation a= nd the actual file access. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M67780= 10ee676c3e2eca3101e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17127514640.39bc18b3a.55872 Date: Wed, 10 Apr 2024 08:17:43 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some replies seem to hold openat() for superfl= uous. In fact, IMHO the traditional syscall open() should be deprecated.

In FreeBSD at least, the libc  open() d= oes in fact use the real thing __sys_openat(). in /usr/src/lib/libc/sys/ope= n.c
via the interposing table.

=
Some days ago, I experimented with a user space implementation of the = of the file lookup in namei() to get the benefits of a  proc specific = namespace on my FreeBSDsystem, making Plan9 style bind and mount  avai= lable. This involved changing every  slash in a path name into  o= penat() calls for the splltted path components. pkeus.de/~wb/ns.c

Btw, = there is another syscall in FreeBSD, which overlaps open() and openat() , n= amely fhopen(). This seems to isolate the namespace lookup operation and th= e actual file access.


= --17127514640.39bc18b3a.55872--