[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] usb-storage: Add rerror/werror properties

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] usb-storage: Add rerror/werror properties
Date: Tue, 26 Jun 2018 10:35:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> The error handling policy was traditionally set with -drive, but with
> -blockdev it is no longer possible to set frontend options. scsi-disk
> (and other block devices) have long supported qdev properties to
> configure the error handling policy, so let's add these options to
> usb-storage as well and just forward them to the internal scsi-disk
> instance.
> Signed-off-by: Kevin Wolf <address@hidden>

Let's see whether I remember / figure out how this stuff works.

Not all devices support error handling policy, but scsi-disk does.

The preferred way to configure error handling policy is with qdev
properties rerror, werror.  blkconf_apply_backend_options() propagates
them to the associated BlockBackend.

The outmoded way is with -drive parameters rerror, werror.
blockdev_init() propagates them to the BlockBackend.

If you use both ways, qdev properties win.

usb-storage is a hack: it tries to look like a block device, but it's
really a SCSI controller that can serve only a single scsi-disk device,
which it creates automatically.

We want to deprecate -drive.  We also want to deprecate usb-storage, but
I guess we're still not ready for that (it's a complicated story).

To deprecate -drive without also deprecating usb-storage, we need to
preserve features.

The outmoded way works with usb-storage: the automatically created
scsi-disk is associated with the BlockBackend that got its error
handling policy from -drive.

The preferred way doesn't, because usb-storage lacks the qdev
properties.  This patch adds them.

Kind of sad, but it's either that or deprecating usb-storage.

Patch looks good to me, thus
Reviewed-by: Markus Armbruster <address@hidden>

Feel free to work whatever parts of my ramblings you find useful into
your commit message.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]