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. :-)
True.
>>> +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
signature.asc
Description: OpenPGP digital signature
