From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <326364c20801141230i3970e6fctb9af49b061a36ece@mail.gmail.com> Date: Mon, 14 Jan 2008 15:30:58 -0500 From: "Tom Lieber" 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: 2e289196-ead3-11e9-9d60-3106f5b1d025 On Jan 14, 2008 3:10 PM, roger peppe wrote: > 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? It seems that all that really matters in a read-only filesystem is which files are available, and what you get when you read them. I imagine writing a filesystem in rc with two functions called by the 9p wrapper code: one for ls, and one for reading the entire file. A completely pass-through filesystem would return `{ ls -l $realdir/$path } for directory listings and `{ cat $realdir/$path } for read requests. Others would pipe file data through other programs, or return its own list of synthetic files instead of ls output. It would all be very inefficient and hackish and really easy to churn out. Writing to files? I'll think about that later. 'Course this is all talk by a guy that hasn't even finished the 9p chapter, and I know how annoying idle chat is... I'll get back to writing code after a few more exams. -- Tom Lieber http://AllTom.com/