[...] >>> >>> Almost, but what I had in mind was to just keep one of the macros - be >>> it SET_IOTUNE or SET_IOTUNE_FIELD or whatever the naming is - and then >>> end up with a snippet like the one in the attached patch. >>> >>> Erik >>> >>> PS: Sorry for attaching a patch, but thunderbird's editor truly sucks >>> (pasting from vim is a total nightmare)...big time...and I really have >>> to switch to some normal mail client. >>> >> >> If you 'temporarily' turn off line wrapping for t-bird, then cut-n-paste >> isn't too bad, but attaching a patch was fine. >> > > Yeah, I could have done that, adjusting the message I sent along with > the patch (I also tried selective wrap but that certainly didn't bring > satisfactory results). Instead, I rage quit and thought that attaching > the patch might not just be the worst possible way at all. Anyway, I'm > starting to convince myself that spending several hours configuring mutt > might as well turn out as a plausible solution of all email-related > future problems than sticking with thunderbird after all. > You're young, make the change... I think you have plenty of "tech support" around you in Brno to get through all the 'gotchas'! Learning a new email client could take me much longer ;-) >> Suffice to say what you propose is where I initially started. Then I >> looked at the extended repetition of lines where the only difference was >> "_max"/"_MAX" and "_max_length"/"_MAX_LENGTH" and felt it was better to >> further collapse the way I did... >> >> In any case, see patch 10 for another instance of "parsing" 2 things at >> a time (PARSE_IOTUNE) and patch 11 for adding the _max_length to that. >> In fact the patch 11 shows my entrails with the commented out macros >> (since removed from my branch). >> >> I chose not do the same in patch 4 (IOTUNE_ADD) or patch 9 >> (FORMAT_IOTUNE) because I didn't want to mess with the .args or .xml >> output "adjustments" (e.g. output files). >> >> Personally I'd rather see the 3 variables close to each other rather >> than hunting through the various output trying to see which are set. Way >> too similarity that can "fool" the eyes. >> >> I'd prefer to keep the version of the macro I have since it doesn't >> affect the output/visible order. >> >> John >> > > Well, I do see your point, I just have a different feeling about that. > When I look at the qemuDomainSetBlockIoTune function, I see a bunch of > variables defined, among which all the set_(bytes|iops) variables > reside. Let's consider a massive function where you introduced a macro > to get rid of all the duplicate code. What I expect from the macro is > that I clearly see what parameters it takes so I can very simply > identify which variables will be affected by the macro whatever it is > trying to accomplish. By introducing another macro representing an > additional meta layer of name processing, I fail to see what arguments > will be eventually affected by the macro machinery at first glance. > Your initial idea which was identical to my proposal makes it clear what > variables will be affected by the macro and the only thing that needs to > be handled is prefixing the enums with VIR_DOMAIN_BLOCK_IOTUNE. In my > opinion, by visually grouping the related blocks of code can also lead > to certain amount of cleanliness. > Another thing, since in patch 4 and 9 you went the way I'm currently > describing, I'm not a fan of treating essentially the same thing > differently. > I flipped a coin and it came up heads, which means I'll adjust this code to be more like what you propose. I'll also likewise adjust patch 10 and 11 to PARSE_IOTUNE each variable - just to keep things consistent. Now if I can only work through the RPC issue I put in a reply to .0 <sigh> Tks - John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list