9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Tom Lieber" <alltom@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Easiest way to make a filesystem
Date: Mon, 14 Jan 2008 15:30:58 -0500	[thread overview]
Message-ID: <326364c20801141230i3970e6fctb9af49b061a36ece@mail.gmail.com> (raw)
In-Reply-To: <df49a7370801141210l1ea2434eje6dae25e183801ab@mail.gmail.com>

On Jan 14, 2008 3:10 PM, roger peppe <rogpeppe@gmail.com> 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/


  reply	other threads:[~2008-01-14 20:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-14  9:11 Tom Lieber
2008-01-14  9:20 ` Christopher Nielsen
2008-01-14 13:42 ` Eric Van Hensbergen
2008-01-14 20:10   ` roger peppe
2008-01-14 20:30     ` Tom Lieber [this message]
2008-01-14 20:40     ` hiro
2008-01-14 21:00     ` Gary Wright
2008-01-14 21:10       ` roger peppe
2008-01-14 21:23         ` Gary Wright
2008-01-14 21:29     ` Roman Shaposhnik
2008-01-15 12:22       ` roger peppe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=326364c20801141230i3970e6fctb9af49b061a36ece@mail.gmail.com \
    --to=alltom@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).