[Xorp-hackers] Using results from one XRL to respond to another
Steven Simpson
ss at comp.lancs.ac.uk
Thu Mar 10 08:02:51 PST 2011
Hi Ben,
On 08/03/11 18:07, Ben Greear wrote:
> First: It seems at least some of the 3rd patch is changing code from the
> first or second patch. This increases the amount of code review needed,
> so I'm hoping you can re-work this so that the third patch is merged
> into the previous patch(es). You are welcome to have more smaller
> patches,
> just don't have a later patch do changes to the previous ones if
> possible.
I just sent the output of 'git format-patch'; thought it might have
generated just one patch, but it didn't and I couldn't find an option to
collapse them. I'd rather have sent just one anyway - they're not
functional individually, just compilable. I now seem to have managed to
produce a single patch with all changes, though that may be redundant in
light of the potential #ifdef requirement...
> Second: I *think* you are using '0' when you are passing a NULL pointer.
> Please use 'NULL' instead so it's obvious it's a pointer type and not an
> integer value. I know that they are in practice equivalent on any modern
> architecture...
Hmm, I suspect I saw 0 being used somewhere already (in
FinderMessengerBase::dispatch_xrl?), and assumed it was the local
convention. I will use NULL, however, as you request.
> Third: Please compare the size of the stripped binaries before and after
> your changes. If your changes cause a significant increase in disk space
> usage, we may want to allow them to be #ifdef'd out: There are folks who
> are trying to use xorp with very small storage systems. You can check
> the SConstruct file for examples of how to compile out things (see
> 'disable_profile', etc).
I think I counted about 2MB increase stripped and using
disable_warninglogs=True disable_tracelogs=True disable_fatallogs=True
disable_infologs=True disable_assertlogs=True disable_errorlogs=True
disable_otherlogs=True disable_profile=True, and 7MB unstripped. I
expect it's all the inlined template instantiations for callbacks...?
It sounds like a lot, so I'm having a go at an #ifdef'd version.
XORP_ENABLE_ASYNC_SERVER is the macro name, and enable_async_server is
the scons argument. Let me know if you prefer other names.
Btw, disable_profile=True also raised an error in olsr4.tgt, so I had to
temporarily remove profile/0.1 to get beyond it.
> Fourth: Please add more verbose descriptions to the individual patches.
Will do.
> And finally: I'd like a:
>
> Signed-off-by: [you] <your-email>
Oh, so that's what that's for! No problem.
Cheers,
Steven
--
More information about the Xorp-hackers
mailing list