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?
