9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@9fans.net
Subject: Re: [9fans] P9p's mount(1) on linux
Date: Thu, 19 Jun 2008 11:10:19 -0400	[thread overview]
Message-ID: <20080619150936.218261E8C45@holo.morphisms.net> (raw)
In-Reply-To: <59247.81.47.192.163.1213873686.squirrel@webmail.kix.es>

Thanks for the patch, Uriel.


The http://swtch.com/v9fs script stopped working
a long time ago, and I never bothered to find
out why.  I've changed the text on that page,
though clicking on the "date and checksums"
link has always shown that the last update
was October 2006.


A few p9p programs--acme, tapefs, vacfs--now
accept a -m option directing them to mount at a
particular place in the directory tree, via 9pfuse.
There is no option to mount via the Linux 9p module.


I'm a little tired of the "Fuse sucks" meme.

The fuse libraries are not so great, but the fuse kernel
interface is completely reasonable, and arguably
a better fit for Unix than 9P is.  A lot of the hard work and
churn in Eric's code is because he's trying to do a good
translation from 9P to Unix VFS.  Fuse lets the
individual file servers take care of that, which is fine
with me.  Also, the FUSE kernel interface, in my
experience, has been a bit more solid and certainly
changes less often.

I think that Fuse gets a bad rap mainly because the
people using it to write file servers don't do a good job.
I've never run into bugs in the fuse kernel driver itself.
User-level file servers are an entirely new concept for
most people (present company excluded), so it's not
surprising that most of the people out there writing
user-level file servers don't fully understand the issues
in what they're implementing.  But the Fuse kernel
developers do.

I wrote a new user-level file server a month ago,
something I hadn't done in years, and I did it on Linux,
using lib9p backed by 9pfuse.  It was an entirely pleasant
experience.


Russ



  reply	other threads:[~2008-06-19 15:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19  1:42 Uriel
2008-06-19  1:57 ` Eric Van Hensbergen
2008-06-19  3:05   ` Uriel
2008-06-19 11:08     ` Rodolfo kix García 
2008-06-19 15:10       ` Russ Cox [this message]
2008-06-19 20:29         ` Uriel
2008-06-19 23:21           ` Russ Cox
2008-06-19 23:40             ` Eric Van Hensbergen
2008-06-19 23:55               ` Skip Tavakkolian
2008-06-19 21:08         ` sqweek
2008-06-19 22:59           ` Russ Cox
2008-06-20  1:34             ` sqweek
2008-06-19 11:35     ` Iruata Souza
2008-06-19 15:53     ` Eric Van Hensbergen
2008-06-19 15:56       ` erik quanstrom
2008-06-19 20:25       ` Uriel
2008-06-19 20:39       ` sqweek
2008-06-19 21:52         ` Eric Van Hensbergen
2008-06-19 22:04       ` Eric Van Hensbergen
2008-06-19 22:46         ` Rob Pike
2008-06-20 12:37         ` sqweek
2008-06-20 13:20           ` Eric Van Hensbergen
2008-06-20 14:59         ` ron minnich
2008-06-19 13:33   ` Sape Mullender

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=20080619150936.218261E8C45@holo.morphisms.net \
    --to=rsc@swtch.com \
    --cc=9fans@9fans.net \
    /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).