From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:48965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzhTZ-0005AV-KX for qemu-devel@nongnu.org; Fri, 01 Mar 2019 07:41:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzhOf-0006zY-Dm for qemu-devel@nongnu.org; Fri, 01 Mar 2019 07:36:14 -0500 Date: Fri, 1 Mar 2019 13:36:08 +0100 From: Kevin Wolf Message-ID: <20190301123608.GB5861@localhost.localdomain> References: <61bbfa3721938326edb03db58a6a246b384f3260.1547739122.git.berto@igalia.com> <20190212180231.GJ5283@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 09/13] block: Add 'runtime_opts' and 'mutable_opts' fields to BlockDriver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Am 01.03.2019 um 13:12 hat Alberto Garcia geschrieben: > On Tue 12 Feb 2019 07:02:31 PM CET, Kevin Wolf wrote: > >> diff --git a/include/block/block_int.h b/include/block/block_int.h > >> index fd0e88d17a..e680dda86b 100644 > >> --- a/include/block/block_int.h > >> +++ b/include/block/block_int.h > >> @@ -345,6 +345,13 @@ struct BlockDriver { > >> > >> /* List of options for creating images, terminated by name == NULL */ > >> QemuOptsList *create_opts; > >> + /* Runtime options for a block device, terminated by name == NULL */ > >> + QemuOptsList *runtime_opts; > > > > I'm not sure if using a QemuOptsList here is a good idea. Currently, > > we use QemuOptsLists for most options, but there are some drivers that > > use it only for part of their options, or not at all, using direct > > QDict accesses or QAPI objects for the rest. > > My intention was to avoid having two separate lists with the runtime > options of a driver. For this feature we really need that list to > contain all options, otherwise there's no way to know whether a missing > option is really missing or if it doesn't exist in the first place. Yes, I understand your intention and the requirement. My point is just that the existing QemuOptsLists are often _not_ complete, so they can't fulfill the requirement. Kevin