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=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI 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 DF3F02393A for ; Wed, 26 Jun 2024 23:44:17 +0200 (CEST) Received: from sendmail.purelymail.com ([34.202.193.197]) by 9front; Wed Jun 26 17:42:39 -0400 2024 DKIM-Signature: a=rsa-sha256; b=Wg4+h3/ca8R1Vzzp9PCqfQRyHMlFusd03b10ZE7mzomVWAiJxOw3PuN6CoM4T2jrgK7cgAy0D+vwp7lFtCNlFSAdMrmz3RPhzpbn+MHWHHHWEcHFm2tuEEluIYLX/dwopPewiNFEx2m4JWcGLzQiNSnK8bYwyYjSVrdE9QZu6FW83EhV0Cf7jy5egOx8zE5K4KCaT7OG1rw9IlkBokuAjz5I6aRC+ek7GdIMu+oOhNVF4WcatN0f+sFIA6+/PN69WB7cqnxZ/q9XLNK5YVu7Yupm94pJjB/njG2g/M2z59H82AFjN8boCwq056CF3sEpjxcFLv3iSRFzWJ92po9xCA==; s=purelymail3; d=pbrane.org; v=1; bh=G24wdK1M7t6bAkA7Z6FkIkKf8NSVKYerxmsPrb9Jt6g=; h=Received:Date:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=G6DF0+sx32fcxEK3RvsVA7hIZzdv9h+LEc+piCn7QoBvxonqRlvDZziPkBCuODalDye6upvBblkbJdY77wrgzHqauHw/4wL1hPz/3mQSfA2nE461zxwvG7n07TxVD9TqxWFJlOG8osWMBacZomK573XsDhMh4FLq1OFrH4tkDOUMFzRFZueDGRaNIkv33mTzTbclUV3UXzxWfSQfGmSidMFjpow+FSU+/q3bvogLIuaF2gzJ4GqcUm6GY6aizXZGtZqGRwSTRTfdX+DybWFpW2lEaUYuIB5h0uVLSp0BNq28UZf5EP9mpF+JcVUObFfuXH5V6x1h+YkKoDU8z67PVw==; s=purelymail3; d=purelymail.com; v=1; bh=G24wdK1M7t6bAkA7Z6FkIkKf8NSVKYerxmsPrb9Jt6g=; h=Feedback-ID:Received:Date:From:To:Subject; Feedback-ID: 10987:2443:null:purelymail X-Pm-Original-To: 9front@9front.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1907425473 for <9front@9front.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 26 Jun 2024 21:42:30 +0000 (UTC) Date: Wed, 26 Jun 2024 14:42:24 -0700 From: Anthony Martin To: 9front@9front.org Message-ID: References: <3fc9a9b9-931d-41eb-a6ae-edf45f876a63@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3fc9a9b9-931d-41eb-a6ae-edf45f876a63@app.fastmail.com> X-MIME-Autoconverted: from 8bit to quoted-printable by Purelymail List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized extensible event high-performance proxy lifecycle plugin Subject: [9front] Re: Design principles for Plan 9 file systems? Reply-To: 9front@9front.org Precedence: bulk Jo=C3=ABl Franusic once said: > 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. The 9P protocol gives you a uniform API for interacting with a resource: open, read, write, close. How you represent a specific resource depends on what the resource is or does. There are some clear patterns that most file systems use to model their resources: - single control file - multiple control files - control file and data file - filter - multiplexer - protocol converter It's not a coincidence that all of them have roots in signal processing and telecom work. Bell Labs was part of the phone company after all. Study Sandy Fraser's work if you seek enlightenment. As for what goes into the control files, it's usually simple messages akin to writing registers on a device or setting up a call on a switch. Deviation from this is unusual. Cheers, Anthony