On 04.07.2016 12:50, Kevin Wolf wrote:
> Am 02.07.2016 um 18:15 hat Max Reitz geschrieben:
>> On 30.06.2016 16:13, Kevin Wolf wrote:
>>> +        echo "info block" \
>>> +            | run_qemu -drive "$drive,cache=$cache" \
>>> +                       -device "ide-hd,drive=none0$wce" \
>>> +            | grep -e "Testing" -e "Cache mode"
>>
>> Something interesting: If you'd specify the drive through a node name,
>> then the BDS tree has two BBs, one implicitly created with -drive (this
>> one is named (automatically) and owned by the monitor) and an anonymous
>> one for the device. If the device then overrides the cache mode, this
>> will not be reflected in the monitor-owned BB. "info block" (and
>> query-block) use the monitor BBs, however, so they'll report the BB on
>> top of the BDS tree in question to be in whatever mode has been
>> specified in -drive, whereas the mode the device uses for accessing that
>> BDS tree actually has nothing to do with that.
>>
>> So the user has no way of inquiring the cache mode used by the device,
>> and they actually get presented misleading information.
> 
> Yes, I know. Originally I wanted to add test cases that use node-name,
> but then it occurred to me that this would be pretty pointless.
> 
> I'm not sure yet what the conclusion is. Change query-block to include
> anonymous BBs that are owned by devices? A new query command? Add the
> information to info qtree and whatever the QMP version of it is (if it
> even exists)?

Well, since you are basically trying to purge the BB from the user's
field of view, it would probably make sense to display all the BB-level
information (like the writethrough mode) as part of the device
information; that is, probably in info qtree. That information should
then probably also include the node name of the root BDS, and the
user/management application can find out all about that with
query-named-block-nodes (although it'd probably makes sense to add a
query-block-node command for a single node).

Max

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to