9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9P vs. FUSE
Date: Fri, 10 Aug 2007 15:26:10 -0400	[thread overview]
Message-ID: <b559084c1914759789ed7d4b8db3ee29@quanstro.net> (raw)
In-Reply-To: <cf8ea346c17aba0c04cc2ee3a288ef35@terzarima.net>

> > is that all files are equal, and doing away with abominations like
> > symlinks, device nodes and ioctls.
> 
> the 9P semantics for those things would be `wrong' (for the suggested use) anyway.
> a remote 9P's device node would access the remote device, not the local one, which
> is useful, but not for remotely-mounting roots.

ioctl allows one to pass a pointer into the kernel, doesn't it?
it's kind of hard to pass a pointer via 9p. ;-)

i believe that research unix also suffered from this problem,
but hacked around it by including 64 bytes starting with
the ptr in question.

> the basic problem, which i expect will never be addressed by the linux people,
> is that mknod and major and minor device numbers were of their time and now
> past their prime.  (that's just one of the things that ``smells really bad''.)

one of the things about plan 9 that looks better and better as you use
it is the fact that devices are fileservers, not special inodes.  this allows
one device to present many files easily, reducing the need for the things
in unix that didn't work so well.

- erik


      reply	other threads:[~2007-08-10 19:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-10 11:42 Enrico Weigelt
2007-08-10 11:57 ` Skip Tavakkolian
2007-08-10 12:19 ` Iruata Souza
     [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com>
2007-08-10 12:33   ` Enrico Weigelt
2007-08-10 12:36     ` erik quanstrom
2007-08-10 12:42       ` Lucio De Re
     [not found]     ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net>
2007-08-10 12:48       ` Enrico Weigelt
2007-08-10 13:18         ` erik quanstrom
     [not found]         ` <f17c25af999bb93211e069e6109bb154@quanstro.net>
2007-08-10 13:36           ` Enrico Weigelt
2007-08-10 13:42             ` andrey mirtchovski
2007-08-10 13:44             ` erik quanstrom
2007-08-10 13:45     ` Eric Van Hensbergen
2007-08-10 15:51       ` ron minnich
2007-08-10 16:32         ` Latchesar Ionkov
2007-08-10 16:39           ` Eric Van Hensbergen
2007-08-10 18:16           ` ron minnich
2007-08-10 18:25             ` Latchesar Ionkov
2007-08-10 18:35               ` Eric Van Hensbergen
2007-08-10 19:16       ` Uriel
2007-08-10 19:21         ` ron minnich
2007-08-10 19:29           ` Charles Forsyth
2007-08-10 21:57             ` ron minnich
2007-08-10 19:29         ` Eric Van Hensbergen
2007-08-10 19:32         ` Latchesar Ionkov
2007-08-10 19:02     ` Uriel
2007-08-10 19:21       ` Charles Forsyth
2007-08-10 19:26         ` erik quanstrom [this message]

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=b559084c1914759789ed7d4b8db3ee29@quanstro.net \
    --to=quanstro@quanstro.net \
    --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).