[libvirt] [PATCH 17/30] remote: Remove virConnectPtr from error/errorf

Matthias Bolte matthias.bolte at googlemail.com
Fri Apr 9 00:03:09 UTC 2010


2010/4/5 Eric Blake <eblake at redhat.com>:
> On 04/04/2010 11:36 AM, Matthias Bolte wrote:
>> Also unify error/errorf to remoteError and update cfg.mk accordingly.
>
>> +++ b/src/remote/remote_driver.c
>> @@ -239,11 +239,9 @@ static int remoteAuthSASL (virConnectPtr conn, struct private_data *priv, int in
>>  static int remoteAuthPolkit (virConnectPtr conn, struct private_data *priv, int in_open,
>>                               virConnectAuthPtr auth);
>>  #endif /* HAVE_POLKIT */
>> -#define error(conn, code, info)                                 \
>> -    virReportErrorHelper(conn, VIR_FROM_QEMU, code, __FILE__,   \
>> -                         __FUNCTION__, __LINE__, "%s", info)
>> -#define errorf(conn, code, ...)                                 \
>> -    virReportErrorHelper(conn, VIR_FROM_QEMU, code, __FILE__,   \
>> +
>> +#define remoteError(code, ...)                                    \
>> +    virReportErrorHelper(NULL, VIR_FROM_REMOTE, code, __FILE__,   \
>>                           __FUNCTION__, __LINE__, __VA_ARGS__)
>
> I like the renaming, especially since our use of the fixed-arg
> preprocessor macro error() was at odds with glibc's variadic function of
> the same name.
>
> ACK, and the rest of the patch is mechanical fallout.

Thanks, pushed.

>> @@ -825,8 +824,9 @@ doRemoteOpen (virConnectPtr conn,
>>      case trans_unix:
>>      case trans_ssh:
>>      case trans_ext:
>> -        error (conn, VIR_ERR_INVALID_ARG,
>> -               _("transport methods unix, ssh and ext are not supported under Windows"));
>> +        remoteError(VIR_ERR_INVALID_ARG, "%s",
>> +                    _("transport methods unix, ssh and ext are not supported "
>> +                      "under Windows"));
>
> I see why you broke this line, to fit 80 columns, but that can impact
> grep-ability of the original message.  Is there any policy on this?
>

I'm not aware of any policy for this, but we have many error messages
split into multiple lines already.

Matthias




More information about the libvir-list mailing list