qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] block: add bdrv_get_device_or_node_name()


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/3] block: add bdrv_get_device_or_node_name()
Date: Fri, 20 Mar 2015 09:47:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Alberto Garcia <address@hidden> writes:

> On Fri, Mar 20, 2015 at 08:40:32AM +0100, Markus Armbruster wrote:
>
>> > +const char *bdrv_get_device_or_node_name(const BlockDriverState *bs)
>> > +{
>> > +    return bs->blk ? blk_name(bs->blk) : bs->node_name;
>> > +}
>> > +
>> 
>> Does this have uses beyond identifying @bs to the user?
>
> None that I can think of, although apart from error messages it can
> also be used in data types, like the cases of BLOCK_IMAGE_CORRUPTED
> and BlockJobInfo that are being discussed:
>
>    https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg03651.html

Workable because BB and BDS names share a common name space.  But is it
a good idea?  No need to discuss this here if it's already discussed
elsewhere.

>> >  static void quorum_report_failure(QuorumAIOCB *acb)
>> >  {
>> > -    const char *reference = bdrv_get_device_name(acb->common.bs)[0] ?
>> > -                            bdrv_get_device_name(acb->common.bs) :
>> > -                            acb->common.bs->node_name;
>> > -
>> > +    const char *reference = bdrv_get_device_or_node_name(acb->common.bs);
>> >      qapi_event_send_quorum_failure(reference, acb->sector_num,
>> >                                     acb->nb_sectors, &error_abort);
>> >  }
>> 
>> Preexisting: what if reference is null?
>
> It can't happen, both the device and the node name strings are
> guaranteed to be non-null. The latter is actually a static string so
> there's no chance bs->node_name returns a null pointer.

You're right, I missed the fact that BDS member node_name is an array.

Suggest to add a function comment to bdrv_get_device_or_node_name()
explaining intended use, and that it never returns null.



reply via email to

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