Re: Flames over -- Re: Which is simpler?

Andrew Morton
2006-02-19T21:02:43Z

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.