Re: [Qemu-devel] [PATCH v6 0/4] Dynamic module loading for block drivers

[Colin Lord]

On 08/02/2016 10:12 AM, Colin Lord wrote:
> I'm sending one more version of this series. v5 didn't seem to need any
> huge makeovers, but I found a small bug in it so I'm hoping it hasn't
> been committed yet. In v5, if a user explicitly specified the driver to
> use, eg driver=gluster, and the driver was modularized, it was not
> correctly detected and qemu would exit since it could not find the
> driver. This series fixes that.
> 
> In addition, the two patches I sent to remove unneeded lines in the
> Makefile and to modularize nfs are included in this series.
> 
> v6:
> - Fix bug so that users can specify a modularized driver on the cli
>   without qemu exiting
> - Remove extra lines from Makefile
> - Add patch to modularize NFS
> 
> v5:
> - No format drivers are modularized, therefore the probe functions are
>   all being left completely untouched.
> - Remove dmg from block-obj-m since it is not a target of the
>   modularization effort.
> - Modify module_block.py to only include the library name and protocol
>   name fields in the generated struct. The other fields are no longer
>   necessary for the drivers that are being modularized.
> 
> v4:
> - Fix indentation of the generated header file module_block.h
> - Drivers and probe functions are now all located in the block/
>   directory, rather than being split between block/ and block/probe/. In
>   addition the header files for each probe/driver pair are in the block/
>   directory, not the include/block/driver/ directory (which no longer
>   exists).
> - Since the probe files are in block/ now, they follow the naming
>   pattern of format-probe.c
> - Renamed crypto probe file to be crypto-probe.c, luks is no longer in
>   the filename
> - Fixed formatting of parallels_probe() function header
> - Enforced consistent naming convention for the probe functions. They
>   now follow the pattern bdrv_format_probe().
> 
> Colin Lord (3):
>   blockdev: prepare iSCSI block driver for dynamic loading
>   blockdev: Add dynamic module loading for block drivers
>   blockdev: Modularize nfs block driver
> 
> Marc Mari (1):
>   blockdev: Add dynamic generation of module_block.h
> 
>  Makefile                        |  10 ++--
>  block.c                         |  62 ++++++++++++++++++++---
>  block/Makefile.objs             |   4 +-
>  block/iscsi.c                   |  36 --------------
>  configure                       |   4 +-
>  include/qemu/module.h           |   3 ++
>  scripts/modules/module_block.py | 108 
> ++++++++++++++++++++++++++++++++++++++++
>  util/module.c                   |  38 ++++----------
>  vl.c                            |  38 ++++++++++++++
>  9 files changed, 226 insertions(+), 77 deletions(-)
>  create mode 100644 scripts/modules/module_block.py
> 
I did want to address one of the items Fam brought up in v5 that I never
replied to, so I'm adding Fam to CC here.

It sounds like since this series removes dmg from the list of
modularized drivers, there is a libbz2 dependency that may get pulled in
from the dmg driver. I believe Fam was suggesting moving that part of
the dmg driver into its own module (although not modularizing the entire
dmg driver). Does that sound like a correct interpretation Fam? I do
like the idea, but I'm a little hesitant to put that into this series
because I'd like to keep this series fairly simple so that hopefully
there doesn't need to be too much more discussion about it. My
internship will be ending soon so I'd prefer this series be finished
sooner rather than later. Also I don't think anything in this series
excludes this idea from being added later if we want. Of course there is
always room for discussion, so if there are other thoughts I'm happy to
listen.

Colin