Tom Haynes wrote:
> Jordan Brown wrote:
>> I'm told that you folks are one of the better places to ask about
>> rpcgen. Please feel free to direct me elsewhere or forward as
>> appropriate.
>>
>> I've inherited a program that uses RPC.
>>
>> For unknown historical reasons, its *_svc.c file has been modified and
>> checked into the repository. This is a nuisance because when I change
>> the *.x file and regenerate the *_svc.c file, I have to hand-merge the
>> changes.
>
> Why not remove the *_svc.c files from source control?
> Are there changes other than the ones to make it pass cstyle and lint?
It's got other differences - in particular, it doesn't include the _msgout
function. It's been hand edited to call the application's logging function
instead.
> Remember that these are moving targets as well.
True. My immediate reaction is that these files are not affected by that
any more or less than any other source files, but that's not true - fixing
a random source file to match a new cstyle requirement is just a matter of
fixing that file, where here it's necessary to both fix the file and fix
rpcgen, and get the fixed rpcgen onto build machines.
Best is to arrange that the file can always be dynamically generated. As
it stands, the message handling mechanism makes that awkward. It looks
like you have three choices: accept rpcgen's undocumented error handling,
use -L and accept its syslog use, or use -L and interpose on syslog. None
of those give me warm fuzzy feelings; I'd like more direct control.
If I can find a way out of the message handling dilemma I'm happy to let
somebody else who can't use dynamic generation worry about cstyle and lint.
Code hygiene does suggest that lint cleanliness is a good thing, so that
people can do proper lint checks against their entire application,
including generated code. That's the minority of the changes here, though;
most were for cstyle cleanliness.
>> The vast majority of the changes are to make the file pass cstyle and
>> lint. It seems like it would be straightforward to fix rpcgen to
>> generate cleaner code, so that the generated code would be as similar
>> as possible to the modified-and-checked-in code, to minimize the work
>> involved in a resync. That seems like a relatively non-controversial
>> bit of work. (Any disagreement?)
>>
>> I did that work, and cleaned up my existing *_svc.c file to eliminate
>> spurious differences between it and the generated file, and found that
>> I only had one difference left, one difference that prevented me from
>> just dynamically generating the file (which would avoid the need to
>> fix the nits mentioned above, though I'd probably fix them anyway).
>> The generated *_svc.c file includes a message handling function
>> _msgout that calls syslog or fprintf(stderr, ...) depending on a
>> couple of flags. My application has its own logging infrastructure,
>> so I don't want to have this one file doing its own thing.
>>
>> I'd like to add a feature to rpcgen to allow the user to customize
>> message handling, so that the generated file can be used directly and
>> there is no need to hand-tweak it and check the file into the repository.
>>
>> The change that I have prototyped is to surround the definition of
>> _msgout with
>> #if !defined(_msgout)
>> ...
>> #endif
>>
>> This then allows one to supply an alternate definition using % lines
>> in the *.x file, e.g.:
>>
>> %#define _msgout my_msgout
>> %extern void my_msgout(char *);
>>
>> or perhaps
>>
>> %#define _msgout(s) printf("RPC: %s\n", (s))
>>
>> I could make this change as a consolidation-private interface, but it
>> seems like it's of more general interest, suggesting an ARC case. At
>> that point it seems like I should involve the owners... which is what
>> brings us here.
>>
>> Any thoughts?
>> _______________________________________________
>> nfs-discuss mailing list
>> nfs-discuss at opensolaris.org
>
>
