Bugzilla – Bug 2246
Some DSR LogComponents and classes are not defined in a unique way
Last modified: 2015-12-19 17:57:24 UTC
Created attachment 2205 [details] DSR Log Components Patch Some files of DSR protocol do not define the LogComponents in a unique way. Example: dsr-passive-buff.cc defines Log Component as NS_LOG_COMPONENT_DEFINE ("PassiveBuffer"); The patch attached here (for ns-3.24) changes all such occurrences to contain "Dsr" as prefix. Example: NS_LOG_COMPONENT_DEFINE ("DsrPassiveBuffer"); Thanks to: Tommaso Regards, Mohit P. Tahiliani
Let me explain the problem and why I do agree with Mohit (we discussed about this). Classes are "protected" by namespaces, while LogComponent space is not. If one duplicates the DSR module (namely, to do some experiments with a modified DSR), he/she can automatically change all the "dsr" strings (with some care about capitalizations) and have a fresh copy to work with. This works for everything BUT for the LogComponents. Unless there's "Dsr" in the name. AODV, DSDV and OLSR already follow this (even though I don't think it was intentional). DSR almost follows the convention, with the only exception of PassiveBuffer. As a side note, I'd rather change the class name as well to, e.g., DsrPassiveBuffer, just because almost all the other Dsr-related classes are starting with Dsr.
(In reply to Tommaso Pecorella from comment #1) > Let me explain the problem and why I do agree with Mohit (we discussed about > this). > > Classes are "protected" by namespaces, while LogComponent space is not. > If one duplicates the DSR module (namely, to do some experiments with a > modified DSR), he/she can automatically change all the "dsr" strings (with > some care about capitalizations) and have a fresh copy to work with. > This works for everything BUT for the LogComponents. Unless there's "Dsr" in > the name. > > AODV, DSDV and OLSR already follow this (even though I don't think it was > intentional). > DSR almost follows the convention, with the only exception of PassiveBuffer. > > As a side note, I'd rather change the class name as well to, e.g., > DsrPassiveBuffer, just because almost all the other Dsr-related classes are > starting with Dsr. I agree with both the proposed logging changes and the class name adjustment.
(In reply to Tom Henderson from comment #2) > (In reply to Tommaso Pecorella from comment #1) > > Let me explain the problem and why I do agree with Mohit (we discussed about > > this). > > > > Classes are "protected" by namespaces, while LogComponent space is not. > > If one duplicates the DSR module (namely, to do some experiments with a > > modified DSR), he/she can automatically change all the "dsr" strings (with > > some care about capitalizations) and have a fresh copy to work with. > > This works for everything BUT for the LogComponents. Unless there's "Dsr" in > > the name. > > > > AODV, DSDV and OLSR already follow this (even though I don't think it was > > intentional). > > DSR almost follows the convention, with the only exception of PassiveBuffer. > > > > As a side note, I'd rather change the class name as well to, e.g., > > DsrPassiveBuffer, just because almost all the other Dsr-related classes are > > starting with Dsr. > > > I agree with both the proposed logging changes and the class name adjustment. Mohit wrote me that he's working on a revised patch. As soon as it's ready I'll check it, I'll rebuild the python bindings and I'll push.
Created attachment 2213 [details] Patch to resolve LogComponent names and Class names in DSR I have attached a revised patch. This takes care of Log Component names and Class names in DSR.
changeset: 11793:d05cb298c103