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

Re: [libvirt] [PATCH] esx: Move CURL handling code to it's own type



2011/4/22 Eric Blake <eblake redhat com>:
> On 04/10/2011 07:39 AM, Matthias Bolte wrote:
>> ---
>>  src/esx/esx_driver.c |    4 +-
>>  src/esx/esx_vi.c     |  348 ++++++++++++++++++++++++++------------------------
>>  src/esx/esx_vi.h     |   29 +++-
>>  3 files changed, 205 insertions(+), 176 deletions(-)
>>
>> +++ b/src/esx/esx_vi.h
>> @@ -82,6 +82,7 @@ typedef enum _esxVI_APIVersion esxVI_APIVersion;
>>  typedef enum _esxVI_ProductVersion esxVI_ProductVersion;
>>  typedef enum _esxVI_Occurrence esxVI_Occurrence;
>>  typedef struct _esxVI_ParsedHostCpuIdInfo esxVI_ParsedHostCpuIdInfo;
>> +typedef struct _esxVI_CURL esxVI_CURL;
>>  typedef struct _esxVI_Context esxVI_Context;
>>  typedef struct _esxVI_Response esxVI_Response;
>>  typedef struct _esxVI_Enumeration esxVI_Enumeration;
>> @@ -142,16 +143,32 @@ struct _esxVI_ParsedHostCpuIdInfo {
>>
>>
>>  /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> + * CURL
>> + */
>> +
>> +struct _esxVI_CURL {
>> +    CURL *handle;
>> +    virMutex lock;
>> +    struct curl_slist *headers;
>> +    char error[CURL_ERROR_SIZE];
>> +};
>> +
>> +int esxVI_CURL_Alloc(esxVI_CURL **curl);
>> +void esxVI_CURL_Free(esxVI_CURL **curl);
>> +int esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri);
>> +int esxVI_CURL_Download(esxVI_CURL *curl, const char *url, char **content);
>> +int esxVI_CURL_Upload(esxVI_CURL *curl, const char *url, const char *content);
>
> A new type...
>
>> +
>> +
>> +
>> +/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>   * Context
>>   */
>>
>>  struct _esxVI_Context {
>> +    esxVI_CURL *curl;
>>      char *url;
>>      char *ipAddress;
>> -    CURL *curl_handle;
>> -    struct curl_slist *curl_headers;
>> -    char curl_error[CURL_ERROR_SIZE];
>> -    virMutex curl_lock;
>>      char *username;
>
> extracted from several fields of a larger type, and the rest of the
> patch looks like mechanical fallout to the different naming to get to
> the same fields.
>
> Looks like a reasonable refactoring, and nothing really caught my eye as
> suspicious.
>
> ACK.
>

Thanks, pushed.

Matthias


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