Re: [libvirt] [PATCH 4/5] remote generator: Make parsing stricter

[Matthias Bolte <matthias bolte googlemail com>]

2011/5/9 Eric Blake <eblake redhat com>:
> On 05/07/2011 06:28 AM, Matthias Bolte wrote:
>> Anchor matches at the beginning of a line.
>>
>> Specialize some general matches.
>>
>> Add some comments to special cases.
>> ---
>>  daemon/remote_generator.pl |  172 +++++++++++++++++++++++++++-----------------
>>  1 files changed, 105 insertions(+), 67 deletions(-)
>>
>> @@ -510,13 +522,29 @@ elsif ($opt_b) {
>>                      }
>>
>>                      unshift(@args_list, $conn);
>> -                } elsif ($ret_member =~ m/hyper (\S+);/) {
>> -                    push(@vars_list, "unsigned long $1");
>> -                    push(@ret_list, "ret->$1 = $1;");
>> -                    $single_ret_var = $1;
>> +                } elsif ($ret_member =~ m/^(unsigned )?hyper (\S+);/) {
>> +                    my $type_name;
>> +                    my $ret_name = $2;
>> +
>> +                    $type_name = $1 if ($1);
>> +                    $type_name .= "long";
>> +
>> +                    if ($type_name eq "long" and
>> +                        $calls{$_}->{ProcName} =~ m/^Get(Lib)?Version$/) {
>> +                        # SPECIAL: virConnectGet(Lib)?Version uses unsigned long
>> +                        #          in public API but hyper in XDR protocol
>> +                        $type_name = "unsigned long";
>> +                    }
>
> Fine for this patch, but we could probably clean it up to use unsigned
> hyper in XDR protocol with no change to the wire format as a separate patch.
>
>> @@ -928,7 +962,8 @@ elsif ($opt_k) {
>>          }
>>
>>          if ($call->{ProcName} eq "NWFilterDefineXML") {
>> -            # fix public API and XDR protocol mismatch
>> +            # SPECIAL: virNWFilterDefineXML has a flags parameter in the
>> +            #          public API that is missing in the XDR protocol
>>              push(@args_list, "unsigned int flags ATTRIBUTE_UNUSED");
>>          }
>
> Ouch.  We need to introduce a new XDR function number that fixes this,
> while keeping glue code in place for the old broken XDR function number
> (of course, as a separate patch).
>
> ACK.
>

Thanks, pushed.

Matthias