[Qemu-devel] BlockBackend next steps

[Qemu-devel] BlockBackend next steps

[Markus Armbruster]

"Need BlockBackend" has been a recurring theme for a long time.  It's
finally on master now.  Plenty of work left to do.  Let's coordinate
next steps to avoid duplicate work.

A few obvious tasks:

* Complete monitor command conversion

  Commands deal with complete backends and with individual nodes or
  sub-trees.  The former need conversion from BlockDriverState to
  BlockBackend.

  Done: qmp_query_block(), qmp_eject(), qmp_change_blockdev().

  Can be done command by command.  Some command conversions depend on
  other conversions.

* Complete utility program conversion (qemu-img qemu-io qemu-nbd)

  Done: BB creation and destruction.

  To be done: actual use.  Can be done program by program.

* Convert internal NBD server

* Convert block migration

* Convert block jobs

  We want to divorce jobs from the block layer, but since that'll
  probably take a while, lift them for now.

* Convert any other users outside the block subsystem

* Lift backend stuff from BDS into BB

  Lift one group of related members at a time.

  A good starting point is bdrv_move_feature_fields().  Examine the
  stuff it moves group by group.  Either move it, or add a comment
  explaining why it should stay.

* Review use of bdrv_get_device_name()

  Some uses might want the node-name instead.

  Double-checking blk_name() use wouldn't hurt.

* Monitor command blockdev-del

  Fail when reference count > 1.

* Monitor commands to force reference count down to 1

  Sometimes, you want to stop using an image, so you can use it for
  something else, e.g. another VM.

  To do that, you need to make its users give up their reference: unplug
  device model, complete block job, unexport from internal NBD server,
  ...

  Need to review everything in QEMU proper that can hold a reference,
  and make sure there's a way to make it drop the reference.

  Known complications:

  * The only way to unexport seems to be stopping the NBD server
    outright.
  
  * When a device model is not pluggable, or refuses to unplug, we need
    to fence it.  The current way to do that is drive_del, which is
    badly designed, needs to be replaced.

  Depends on conversions.

* Get rid of "empty" BDS

  Now: and empty backend is represented as BB with BDS that has a null
  driver.

  Wanted: represented as BB without BDS.

* Get rid of BDS member opaque

  Now: BDS is a concrete data type.  Block drivers use opaque to point
  to their driver-specific state.

  Wanted: BDS is an abstract base.  Block drivers extend it.

  Depends on the previous item.

If you have more, please list them.

Re: [Qemu-devel] BlockBackend next steps

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Thu, Oct 23, 2014 at 02:16:37PM +0200, Markus Armbruster wrote:
> "Need BlockBackend" has been a recurring theme for a long time.  It's
> finally on master now.  Plenty of work left to do.  Let's coordinate
> next steps to avoid duplicate work.

Great job.  Thanks for sending this email.  I haven't followed closely
and it helps me understand the current status.

Looks like many of these tasks can be done in parallel.

> * Convert block jobs
> 
>   We want to divorce jobs from the block layer, but since that'll
>   probably take a while, lift them for now.

Breaking the 1:1 relationship between block jobs and BDS is nice
conceptually, but is there a concrete requirement?  Unless there is a
use case that someone needs supported it's best to focus on more urgent
issues.

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] BlockBackend next steps

[Markus Armbruster]

Stefan Hajnoczi <stefanha@redhat.com> writes:

> On Thu, Oct 23, 2014 at 02:16:37PM +0200, Markus Armbruster wrote:
>> "Need BlockBackend" has been a recurring theme for a long time.  It's
>> finally on master now.  Plenty of work left to do.  Let's coordinate
>> next steps to avoid duplicate work.
>
> Great job.  Thanks for sending this email.  I haven't followed closely
> and it helps me understand the current status.
>
> Looks like many of these tasks can be done in parallel.

Indeed!

>> * Convert block jobs
>> 
>>   We want to divorce jobs from the block layer, but since that'll
>>   probably take a while, lift them for now.
>
> Breaking the 1:1 relationship between block jobs and BDS is nice
> conceptually, but is there a concrete requirement?  Unless there is a
> use case that someone needs supported it's best to focus on more urgent
> issues.

I agree it's not a priority by itself.  It may be required to wean code
outside the block system off BDS.  We'll find out as we do the work.