From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 14 Jan 2008 20:10:02 +0000 From: "roger peppe" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Easiest way to make a filesystem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <326364c20801140111v1bf9b574p80ea0305edf09c14@mail.gmail.com> Topicbox-Message-UUID: 2e20afbc-ead3-11e9-9d60-3106f5b1d025 i agree that it's too hard to create servers for simple filesystems. i've been wondering on and off for years what a "low-bar-to-entry" filesystem creating library might look like, and my current thoughts go something like: - it's the generality of the problem that makes it hard. 9p allows a great deal of freedom in implementing semantics. there's not one design that fits all patterns. - that said, if we restrict the problem, we can make things simpler. inferno's file2chan is an extreme example. 9pfile is an example at the other end of the spectrum. something that deals with stackable filesystems would be another example - but how much generality do you go for? change contents only? change names? add new hierarchies? change blocking behaviour? - it seems to me that most of the time we want "natural" (i.e. standard filesystem) semantics everywhere we don't specify something different. this can be looked at a kind of inheritance, the difficulty being that the inheritance cuts across many possible aspects of the implementation - fids, qids, tags - all of which are expressed in very different ways in code. - perhaps there's room for a new "little language" here; along the lines of yacc, maybe. but, how would we *want* to express the specification for a file server?