2011/5/9 Eric Blake <eblake@xxxxxxxxxx>:
> On 05/07/2011 06:28 AM, Matthias Bolte wrote:
>> ---
>> Âdaemon/Makefile.am         |  20 ++++-
>> Âdaemon/qemu_dispatch.blacklist   |  Â3 +
>> Âdaemon/qemu_dispatch.whitelist   |  Â1 +
>> Âdaemon/remote_dispatch.blacklist  |  37 ++++++++
>> Âdaemon/remote_dispatch.whitelist  | Â169 +++++++++++++++++++++++++++++++++++
>> Âdaemon/remote_generator.pl     | Â171 +++++++++++++-----------------------
>> Âsrc/Makefile.am          Â|  24 ++++-
>> Âsrc/remote/qemu_client.blacklist  |  Â3 +
>> Âsrc/remote/qemu_client.whitelist  |  Â1 +
>> Âsrc/remote/remote_client.blacklist | Â 47 ++++++++++
>> Âsrc/remote/remote_client.whitelist | Â159 +++++++++++++++++++++++++++++++++
>
> Hmm. ÂGiven the difference in sizes between
> daemon/remote_dispatch.whitelist and src/remote/remote_client.whitelist,
> there are some functions where we are only doing half the job?
Yes, seems so. I didn't yet check what's the difference and why there is one.
> ÂThat
> means every new API has to touch two, rather than one, file, and that's
> out of a choice of four files.
>
> Maybe a better thing to do would be having a single file, that lists
> every API, along with two states, as in:
>
>
> # name  daemon Âsrc/remote
> function yes   no
>
> In fact, rather than maintaining separate files, could we instead
> maintain this list directly in {remote,qemu}_protocol.x, via stylized
> comments?
>
> enum remote_procedure {
> Â Â/* Each function must have a two-word comment. ÂThe first word is
> Â Â * whether remote_generator.pl handles daemon, the second whether
> Â Â * it handles src/remote. Â*/
> Â ÂREMOTE_PROC_OPEN = 1, /* yes no */
> ...
>
> That way, when we add a new API, we are _already_ editing the file that
> contains the white/blacklist, and have the precedence of the lines
> beforehand to remind us whether we need to write manual code or rely on
> the generator.
>
> Although I think that this patch does a good job as-is, I think it is
> worth a v2 that avoids the extra files (the fewer files you have to edit
> when adding a new API, the better).
Yes, that's a way better approach. I'll rework this patch to do that instead.
>> -remote_dispatch_bodies.h: $(srcdir)/remote_generator.pl $(REMOTE_PROTOCOL)
>> - Â Â $(AM_V_GEN)perl -w $(srcdir)/remote_generator.pl -c -b remote $(REMOTE_PROTOCOL) > $@
>> +remote_dispatch_bodies.h: $(srcdir)/remote_generator.pl $(REMOTE_PROTOCOL) \
>> + Â Â Â Â Â Â $(REMOTE_PROTOCOL_WHITELIST) $(REMOTE_PROTOCOL_BLACKLIST)
>> + Â Â $(AM_V_GEN)perl -w $(srcdir)/remote_generator.pl -c -b remote $(REMOTE_PROTOCOL) \
>> + Â Â Â $(REMOTE_PROTOCOL_WHITELIST) $(REMOTE_PROTOCOL_BLACKLIST) > $@
>
> In fact, if the white/black list is part of the .x file, then you don't
> need to tweak this part of the Makefile to pass in the names of extra files.
>
>> +++ b/daemon/remote_generator.pl
>> @@ -23,9 +23,29 @@ use Getopt::Std;
>> Âour ($opt_p, $opt_t, $opt_a, $opt_r, $opt_d, $opt_c, $opt_b, $opt_k);
>> Âgetopts ('ptardcbk');
>>
>> -my $structprefix = $ARGV[0];
>> +my $structprefix = shift or die "missing prefix argument";
>> +my $protocol = shift or die "missing protocol argument";
>> +my $whitelistname;
>> +my $blacklistname;
>> +my @whitelist;
>> +my @blacklist;
>> +
>> +if ($opt_b or $opt_k) {
>> + Â Â$whitelistname = shift or die "missing whitelist argument";
>> + Â Â$blacklistname = shift or die "missing blacklist argument";
>> +
>> + Â Âopen(WHITELIST, "<$whitelistname") or die "cannot open $whitelistname: $!";
>> + Â Â@whitelist = <WHITELIST>;
>> + Â Âclose(WHITELIST);
>> + Â Âchomp(@whitelist);
>> +
>> + Â Âopen(BLACKLIST, "<$blacklistname") or die "cannot open $blacklistname: $!";
>> + Â Â@blacklist = <BLACKLIST>;
>> + Â Âclose(BLACKLIST);
>> + Â Âchomp(@blacklist);
>
> Of course, if the whitelist is maintained in the .x file itself, you'll
> have to rework this (I guess you have to read the whitelist comments
> before doing any further processing on individual functions and struct
> generation that occurred earlier in the file, but doing two passes
> through the .x file in the perl script isn't that bad).
This can still be handled in one pass. Before any output is generated
the complete .x is parsed. The while and blacklist information is
completely read before any output is generated.
>> Â Â Âforeach (@keys) {
>> Â Â Â Â Â# skip things which are REMOTE_MESSAGE
>> Â Â Â Â Ânext if $calls{$_}->{msg};
>>
>> - Â Â Â Âif (exists($ug{$calls{$_}->{ProcName}})) {
>> + Â Â Â Â# ignore procedures on the blacklist
>> + Â Â Â Âif (exists($black{$calls{$_}->{ProcName}})) {
>> + Â Â Â Â Â Âif (exists($white{$calls{$_}->{ProcName}})) {
>> + Â Â Â Â Â Â Â Âdie "procedure $calls{$_}->{ProcName} on whitelist and blacklist";
>
> And by maintaining a 'yes|no' comment in the .x file, instead of two
> separate .whitelist and .blacklist files, you merely need check for a
> well-formed comment rather than comparing two lists for duplicates or
> omissions.
Yep, embedding the while/black information in the .x files makes things simpler.
Matthias
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list