[Top][All Lists]

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

Re: [Qemu-block] [PATCH v3 07/14] blockdev: Add list of monitor-owned Bl

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v3 07/14] blockdev: Add list of monitor-owned BlockBackends
Date: Sat, 20 Feb 2016 14:36:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 20.02.2016 14:34, Max Reitz wrote:
> On 17.02.2016 17:20, Kevin Wolf wrote:
>> Am 17.02.2016 um 16:41 hat Max Reitz geschrieben:
>>> On 17.02.2016 11:53, Kevin Wolf wrote:
>>>> Am 16.02.2016 um 19:08 hat Max Reitz geschrieben:
>>>>> The monitor does hold references to some BlockBackends so it should have
>>>> s/does hold/holds/?
>>> It was intentional, so I'd keep it unless you drop the question mark.
>> For me it seems to imply something like "contrary to your expectations",
>> but maybe that's just my non-native English needing a fix.
>> I don't find it surprising anyway that the monitor holds BB references.
> The contrast I tried to point out is that while we do have these
> references in theory, and they are reflected by a refcount, too, we do
> not actually have these references because the monitor does not yet have
> a list of the BBs it owns.
> So it's not an "emphasize the verb because it may be contrary to your
> expectations", but an "emphasize it because it is contrary to what the
> current code does" (which is not actually referencing these BBs).
> Like: It is supposed to have references. It says it does. But it
> actually doesn't. It does "hold" them, however, because they are
> accounted for in the BBs' refcounts.
>>>>> a list of those BBs; blk_backends is a different list, as it contains
>>>>> references to all BBs (after a follow-up patch, that is), and that
>>>>> should not be changed because we do need such a list.
>>>>> monitor_remove_blk() is idempotent so that we can call it in
>>>>> blockdev_auto_del() without having to care whether it had been called in
>>>>> do_drive_del() before. monitor_add_blk() is idempotent for symmetry
>>>>> reasons (monitor_remove_blk() is, so it would be strange for
>>>>> monitor_add_blk() not to be).
>>>>> Signed-off-by: Max Reitz <address@hidden>
>>>> I think hmp_drive_add() needs a monitor_remove_blk() in its error path.
>>> You're right, thanks.
>>> In addition, if we really do say that a BB having a name equals being
>>> referenced by the monitor, then maybe we don't need explicit calls to
>>> monitor_add_blk() because any BB that is created with a non-NULL name
>>> should be automatically added to the list of monitor BBs.
>> While probably workable, I'd rather avoid this kind of magic where the
>> presence of a name parameter decides whether a reference is taken or
>> not. It makes the interface of the function a lot less obvious.
> Still you want the name to be the monitor's reference to the BB. Thus,
> if monitor_add_blk() should not be called implicitly by blk_new(), then
> I'd instead move the @name parameter from blk_new() to monitor_add_blk().

...aaand I noticed that this is what you said for patch 8 anyway. Good.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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