On 12/14/06, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:

On 13/12/06 22:35, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> wrote:
> The following patch adds a --force option to detach operations. It
> avoids the device being held forever when frontend fails.
Looks good. I think --force should be more brutal (i.e., assume that we have
already politely requested the disconnection, if that's what we really
wanted).

How can we be more brutal than that ? The only non-brutal thing I've put there
is denying disconnection when still in Connected state. But if for
some reason the frontend does not want to disconnect, then the tools
have no power over it. It can simply crash guest.
Example: attach a device, mount it at guest, and try to detach it
using --force. It should not force it, as it crashes the guest.

Apart from that, we should remember that if we need to use --force then it
probably indicates a problem in the frontend driver. If you can repro a
situation that requires --force then we should investigate that (and work
out a patch for blkfront).

Not exactly. The example I'm tracking is as follow:
* try attaching a file:///<valid_file> as sda, after modprobing
sd_mod at guest.
* guest is not able to allocate it a major, and fails like this:
Registering block device major 8
register_blkdev: cannot get major 8 for sd
xen_blk: can't get major 8 with name sd
Besides, there are many situations in which the underlying block layer
can fail (out of memory, and so on). And it does not necessarily means
a bug in the frontend device.
I do however agree that in the general case, it is a good indicator.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
Add your comments to GPLv3 at:
http://gplv3.fsf.org/comments/gplv3-draft-2.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel