[9fans] hot plugging

[9fans] hot plugging

[Fco. J. Ballesteros]

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?

Re: [9fans] hot plugging

[Russ Cox]

I think that these are two different issues.  No matter what
the right way is to present the ever-changing hardware to
the user, there is plenty of restructuring to do just to track
the ever changing hardware at the hardware level itself.

Russ

Re: [9fans] hot plugging

[Francisco Ballesteros]

Of course, the drivers (and its framework) must admit
you to plug in/out the hw without crashing the system :-)
And you have to handle dependencies between them.

On 9/9/05, Russ Cox <rsc@swtch.com> wrote:
> I think that these are two different issues.  No matter what
> the right way is to present the ever-changing hardware to
> the user, there is plenty of restructuring to do just to track
> the ever changing hardware at the hardware level itself.
> 
> Russ
>