9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Fco. J. Ballesteros" <nemo@lsub.org>
To: 9fans@cse.psu.edu
Cc: jmk@plan9.bell-labs.com, quanstro@speakeasy.net
Subject: [9fans] hot plugging
Date: Fri,  9 Sep 2005 20:48:10 +0200	[thread overview]
Message-ID: <ab45a1f8dee5240c0ed5e80350f85fc7@lsub.org> (raw)

I think that there are several problems here.
One is the ability to switch from one device to another.
Another is what to do with the "state" of the device going out.

In Plan B, after several attempts that did mess things up,
I found that in general, what to do with the "state" depends
on the application. In general, raising an error for an ongoing
request is what we do. The application knows if it's ok to retry or
to abort.

If we talk about drivers, what to do may depend on the driver.
For example, for non reliable networks it may be ok just to switch the
ether card (there are other tcp/ip issues here though). For disks, 
it depends on the application, once again.

However, regarding the first problem, the volume mechanism is
a satisfactory answer; For example, say you:

mount -bV #ether /net

This means: take any resource named "#ether", and mount it (-b)
at /net. If one ethernet is not available, the mount mechanism
picks up another.

Thus, I'd say this is a clean way to fix up the first problem.

Right now, I'm in the process of implementing a volfs that works
both for Plan 9 and Plan B, in an effort to reconcile both systems.

If the mechanism were incorporated into the kernel instead, I don't
see why not could it mount in-kernel volumes, to make the example above
work.

Just an idea. Comments?


             reply	other threads:[~2005-09-09 18:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 18:48 Fco. J. Ballesteros [this message]
2005-09-09 18:51 ` Russ Cox
2005-09-09 19:02   ` Francisco Ballesteros

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=ab45a1f8dee5240c0ed5e80350f85fc7@lsub.org \
    --to=nemo@lsub.org \
    --cc=9fans@cse.psu.edu \
    --cc=jmk@plan9.bell-labs.com \
    --cc=quanstro@speakeasy.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).