[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] [PATCH 03/12] block: Introduce BlockBacken

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 03/12] block: Introduce BlockBackendPublic
Date: Wed, 23 Mar 2016 15:35:40 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/23/2016 03:09 AM, Kevin Wolf wrote:
>>> +++ b/block/block-backend.c
>>> @@ -33,6 +33,7 @@ struct BlockBackend {
>>>      DriveInfo *legacy_dinfo;    /* null unless created by drive_new() */
>>>      QTAILQ_ENTRY(BlockBackend) link;         /* for block_backends */
>>>      QTAILQ_ENTRY(BlockBackend) monitor_link; /* for monitor_block_backends 
>>> */
>>> +    BlockBackendPublic public;
>> Any reason to not put the public struct at offset 0?
> No, but also no reason to put it there. :-)


>>> +typedef struct BlockBackendPublic {
>>> +} BlockBackendPublic;
>> No fields?  So really all we need this for is so that we can have an
>> address of a member of the larger struct, so that we can do list
>> operations based on that address?
> Well, a list still needs a QLIST_ENTRY, otherwise I could have directly
> used BlockBackend. I just tried to keep the introduction of .public
> separate from the addition of a specific list.
> I think it's strictly speaking invalid C to have an empty struct, but
> gcc compiles it and so I thought it should be acceptable to have one for
> a single commit until something is added there.

clang gripes; see commit 83ecb22ba.

But breaking bisection for one patch on clang-only is different than
breaking bisection on all compilers, so up to you what you want to do
about it.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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