All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Lord <clord@redhat.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org, mreitz@redhat.com,
	Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v6 0/4] Dynamic module loading for block drivers
Date: Tue, 2 Aug 2016 10:17:47 -0400	[thread overview]
Message-ID: <1c794ef7-3c5a-a95c-7158-1cd1f0773f23@redhat.com> (raw)
In-Reply-To: <1470147137-21970-1-git-send-email-clord@redhat.com>

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

  parent reply	other threads:[~2016-08-02 14:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02 14:12 [Qemu-devel] [PATCH v6 0/4] Dynamic module loading for block drivers Colin Lord
2016-08-02 14:12 ` [Qemu-devel] [PATCH v6 1/4] blockdev: prepare iSCSI block driver for dynamic loading Colin Lord
2016-08-08 15:18   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-08-08 17:54     ` Colin Lord
2016-08-02 14:12 ` [Qemu-devel] [PATCH v6 2/4] blockdev: Add dynamic generation of module_block.h Colin Lord
2016-08-08 15:20   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-08-02 14:12 ` [Qemu-devel] [PATCH v6 3/4] blockdev: Add dynamic module loading for block drivers Colin Lord
2016-08-08 15:22   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-08-02 14:12 ` [Qemu-devel] [PATCH v6 4/4] blockdev: Modularize nfs block driver Colin Lord
2016-08-08 15:23   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-08-02 14:17 ` Colin Lord [this message]
2016-08-03  6:28   ` [Qemu-devel] [PATCH v6 0/4] Dynamic module loading for block drivers Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c794ef7-3c5a-a95c-7158-1cd1f0773f23@redhat.com \
    --to=clord@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.