From: rbnsw-plan9@yahoo.com.au
To: 9fans@9fans.net
Subject: Re: [9fans] RFS alternatives (Was: Living with Plan 9)
Date: Tue, 21 Jun 2011 10:35:16 -0700 [thread overview]
Message-ID: <973562.76924.qm@web30906.mail.mud.yahoo.com> (raw)
--- On Tue, 21/6/11, Eric Van Hensbergen <ericvh@gmail.com> wrote:
...
>> Um, does v9fs remote Linux devices? I find it hard to
>> imagine it would remote ioctls but it makes sense *nix to
>> *nix.
>>
>
> Depends on how you configure it. There is a nodevmap
> option to the v9fs mount which will instruct it to just access
> the remote devices directly instead of just mapping their major/minor
> numbers to local devices. You are correct in your imagining that we
> don't go anywhere near ioctls with a 10 foot pole. However, many things
> "just work" without ioctls these days.
>
Thanks for the info, but the devices encumbered with ioctls are the tricky ones and even if they can be sorted out I'm sure there are some other traps out there. Too bad there are no RFS gurus lurking here to offer their wisdom on remoting devices. I have a sneaking suspicion few people would have bothered, since the few devices worth remoting back then were easily handled by rsh/rcmd. Did RFS make it beyond SVR4?
> >
> > That just leaves my issues with X.
> >
>
> Actually, its a bit worse than that. The physical
> network devices aren't file system accessible anymore,
Actually, I'd blotted out of my mind all knowledges of STREAMs devices and the related horror of TLI programming until you reminded me.
> so you'd need to remote them as a service (via Inferno or something) or
> use the tap device and remote that and hope that it doesn't require ioctls (and I think it might).
>
Oh, I'm not worried about remoting network interfaces. I'm fine with packet forwarding and can live with NAT for now. However, it reminds me of another point in Plan 9's favour that the introductory papers should be updated to be more explicit about - NATs are unnecessary in a pure Plan 9 deployment. Unfortunately, neither Plan 9 routers or decent alternatives to NAT such as RSIP widely available.
> -eric
>
Andrew
P.S. There's spammers subscribed to this list. Hi there, friends of Khalifa.
next reply other threads:[~2011-06-21 17:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 17:35 rbnsw-plan9 [this message]
2011-06-21 22:42 ` dave.l
2011-06-22 15:16 ` Charles Forsyth
-- strict thread matches above, loose matches on Subject: below --
2011-06-27 17:07 rbnsw-plan9
2011-06-27 17:20 ` ron minnich
2011-06-27 17:45 ` Jeff Sickel
2011-06-27 18:18 ` Skip Tavakkolian
2011-06-27 19:13 ` dexen deVries
2011-06-27 20:17 ` erik quanstrom
2011-06-27 21:23 ` dexen deVries
2011-06-30 15:31 ` Yaroslav
2011-06-27 18:26 ` Richard Miller
2011-06-27 17:24 ` erik quanstrom
2011-06-30 17:11 ` rbnsw-plan9
2011-06-30 20:07 ` erik quanstrom
2011-06-11 19:26 rbnsw-plan9
2011-06-21 12:51 ` Eric Van Hensbergen
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=973562.76924.qm@web30906.mail.mud.yahoo.com \
--to=rbnsw-plan9@yahoo.com.au \
--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).