From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id E87BF26A41 for ; Thu, 27 Jun 2024 00:16:12 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Jun 26 18:14:35 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id 8ee2fe76; Wed, 26 Jun 2024 15:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=R8EFWd99Bw4G4pw9KRg5TxTrRI8=; b=WDbs3PgJb4sdQPDRqespl8oFul67 5dabqYFsOUsh1PyF71qvP1YEr7MrX0DtaW1/VYIAGih9VhBqiLUTdQ0ApN476A9w s1bc2BFFH3wFOjNDdrnKr5I1e0fCa/zxdV6tjhHWFZGTaO1aTGwZ0DYqjRmF2rpV bkB7STgGLQec2b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=WRmNQx NPBF1SIow9DrraeIDo+mUTmYVnfBS48oIGT7lDlIMCzzPHz5Aql5xvM5JD7SOaFO gUpKLx51+DAKGIedscdCkqHb6Zbb81HFQUvF9rwYB4xtOJqrL17FBguBa75DyAU/ OLzc9V39GsawKey7ABHDRtgHSXfdpebmv+m/g= Received: from currant.orib.dev (gateway.bk.recurse-network.net [23.136.216.2]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id ec4ab3e2 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed, 26 Jun 2024 15:14:33 -0700 (PDT) Date: Wed, 26 Jun 2024 18:14:31 -0400 From: Ori Bernstein To: 9front@9front.org Cc: =?UTF-8?B?Sm/Dq2w=?= Franusic Message-Id: <20240626181431.f9151c7e2924c462fed22cc8@eigenstate.org> In-Reply-To: <3fc9a9b9-931d-41eb-a6ae-edf45f876a63@app.fastmail.com> References: <3fc9a9b9-931d-41eb-a6ae-edf45f876a63@app.fastmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-unknown-openbsd7.5) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: private app shader ACPI over HTTP scripting DOM optimizer Subject: Re: [9front] Design principles for Plan 9 file systems? Reply-To: 9front@9front.org Precedence: bulk This is a good starting point: https://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiquitous_fileserver.pdf On Wed, 26 Jun 2024 00:50:46 -0700 Joël Franusic wrote: > I'm studying the designs used by user level file servers in Plan 9 (acme, factotum, plumb, etc) and would love to talk to people who have opinions about what good "API" design looks like for a Plan 9 file system. For example: "Which file systems do you like?", "Which are worth studying?", "What are some mistakes to avoid?", etc > > Ultimately, I'd like to come up with a set of guidelines or principles to follow when writing a file server such that a Plan 9 veteran could mount the provided file system and quickly understand how it works. > > For references, here are the "APIs" that I've collected so far, based on what I've found in various research papers: > > ACME > > /mnt/acme/index > > /mnt/acme/new > > /mnt/acme/$n/addr > > /mnt/acme/$n/body > > /mnt/acme/$n/ctl > > /mnt/acme/$n/data > > /mnt/acme/$n/event > > /mnt/acme/$n/tag > > > Factotum > > /mnt/factotum/confirm > > /mnt/factotum/ctl > > /mnt/factotum/log > > /mnt/factotum/needkey > > /mnt/factotum/proto > > /mnt/factotum/rpc > > > Plumb > > /mnt/plumb/rules > > /mnt/plumb/send > > /mnt/plumb/edit > > /mnt/plumb/web > > /mnt/plumb/image > > /mnt/plumb/newmail > > /mnt/plumb/… > > > All of my notes are being kept in a Google Doc for now, which is available here: https://docs.google.com/document/d/1g-GIjJRoa7yfOuSjxYG-owBwVh1QaMzOa5i19vVtxUM/edit?usp=sharing > > -- > Joël Franusic > joel@franusic.com -- Ori Bernstein