Messages in this thread | | | Date | Sun, 19 Feb 2006 13:02:43 -0800 | From | Andrew Morton <> | Subject | Re: Flames over -- Re: Which is simpler? |
| |
Oliver Neukum <oliver@neukum.org> wrote: > > Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton: > > For a), the current kernel behaviour is what we want - make the thing > > appear at a new place in the namespace and in the hierarchy. Then > > userspace can do whatever needs to be done to identify the device, and > > apply some sort of policy decision to the result. > > How? If you have a running user space the connection to the open files > is already severed, as any access in that time window must fail.
That's a separate issue, which we haven't discussed yet. We have a device which has gone away and which might come back later on. Presently we will return an I/O error if I/O is attempted in that window. Obviously we'll need to do something different, such as block reads and block or defer writes.
So an overall picture would be something like:
- When device is not present, reads block and writes are deferred or block
- When device appears (at a new point in the namespace) the hotplug scripts will go off and will identify it and will apply some policy based upon that identification. That policy could be one of:
a) accept device at its new address
b) accept device at its new address, abandon the old address (all those blocked reads and writes suddenly return -EIO).
c) remove device from its new address, splice it back to where it used to be, permit those blocked reads and writes to proceed.
- For devices which are absent-and-blocked, provide some ability for both a timeout and manual cancellation, to unblock all those readers and writers, make them get -EIO.
The number of potential races is, of course, huge. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |