qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 5/5] block: Support GlusterFS as a QEMU block


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v7 5/5] block: Support GlusterFS as a QEMU block backend.
Date: Thu, 20 Sep 2012 17:08:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

Il 20/09/2012 11:34, Kevin Wolf ha scritto:
> Am 20.09.2012 11:12, schrieb Bharata B Rao:
>> On Thu, Sep 20, 2012 at 10:20:33AM +0200, Paolo Bonzini wrote:
>>> Il 20/09/2012 09:53, Paolo Bonzini ha scritto:
>>>>>>> Would look a bit nicer with strstart() form cutils.c instead of 
>>>>>>> strncmp().
>>>>>> strstart() works with const char pointers, but I have char pointers here
>>>>>> which I need to modify.
>>>> You can pass a char* to a function that accepts const char*.  In your
>>>> case, the last argument to strstart would be NULL.
>>>
>>> As you pointed out on IRC, you meant the last argument.  I don't think
>>> it would be a problem to cast that from char ** to const char **.
>>>
>>> Perhaps it would be cleaner to make qemu_gluster_parseuri and
>>> parse_gluster_spec accept a const char *.  You can replace strtok_r +
>>> g_strdup with strspn/strcspn followed by g_strndup.
>>
>> I feel the current approach of using the combination of strncmp, strtok_r
>> and g_strdup should be good enough.
> 
> Now that Paolo agreed that there wouldn't be a problem with casting,
> let's use strstart with a cast to (const char**) for the third
> parameter. Using strtok_r is okay with me.

Just shooting around a possibility: why reinvent the wheel poorly if we
can use a full-blown URI parsing library?  The libxml2 one is very good
and easy to use.

It is also pretty much self-contained and has hardly seen a commit in 3
years, so we can even make it completely self-contained and keep it in
tree.  See attachment, which also includes some functions taken from
libvirt to parse query parameters.

(I know this is controversial and would rather add a build dependency,
but at the same time it is tempting not to).

Paolo

ps: to test the attachment: gcc -I/usr/include/libxml2
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include uri.c -lglib-2.0
&& ./a.out

Attachment: uri.c
Description: Text Data

Attachment: uri.h
Description: Text Data


reply via email to

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