From kohler@icir.org Fri Aug 2 21:11:07 2002 From: kohler@icir.org (Eddie Kohler) Date: Fri, 02 Aug 2002 13:11:07 -0700 Subject: [nsclick-users] integration Message-ID: <200208022011.g72KB7081702@coyote.icir.org> Hi nsclick-users, I just got a chance to look at the nsclick patch for Click. You guys rock! How would you feel about including nsclick in the main Click repository and distribution? I would like that. We could probably get you write permission on the repository. It seems like the majority of the patch is 'namespace SIMCLICK' related. There must be some cleaner way we can do that. Maybe wrap each file (excepting non-Click headers) in 'CLICK_BEGIN'/'CLICK_END' macros, which expand to "namespace SIMCLICK {" / "}" on simclick, and to nothing on the other drivers? Eddie (Kohler) From Michael.Neufeld@colorado.edu Fri Aug 2 22:38:58 2002 From: Michael.Neufeld@colorado.edu (Michael Neufeld) Date: Fri, 02 Aug 2002 15:38:58 -0600 Subject: [nsclick-users] integration References: <200208022011.g72KB7081702@coyote.icir.org> Message-ID: <3D4AFBF2.9080301@colorado.edu> Thanks! Glad you like the patch. We'd love to get nsclick included in the main Click repository. You're right, most of the patch is related to namespacing, and is on the clunky side. The CLICK_BEGIN/CLICK_END solution you suggest sounds fine. It'd definitely be less annoying for folks creating elements. If you could let me know what needs to be done to move forward on integrating nsclick into the main Click repository that would be great. Thanks. -Mike Neufeld Eddie Kohler wrote: > Hi nsclick-users, > > I just got a chance to look at the nsclick patch for Click. You guys rock! > > How would you feel about including nsclick in the main Click repository and > distribution? I would like that. We could probably get you write permission > on the repository. > > It seems like the majority of the patch is 'namespace SIMCLICK' related. > There must be some cleaner way we can do that. Maybe wrap each file > (excepting non-Click headers) in 'CLICK_BEGIN'/'CLICK_END' macros, which > expand to "namespace SIMCLICK {" / "}" on simclick, and to nothing on the > other drivers? > > Eddie (Kohler) > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs.colorado.edu > http://www.cs.colorado.edu/mailman/listinfo/nsclick-users > From kohler@icir.org Mon Aug 5 22:11:50 2002 From: kohler@icir.org (Eddie Kohler) Date: Mon, 05 Aug 2002 14:11:50 -0700 Subject: [nsclick-users] integration In-Reply-To: Message from Michael Neufeld of "Fri, 02 Aug 2002 15:38:58 MDT." <3D4AFBF2.9080301@colorado.edu> Message-ID: <200208052111.g75LBo010859@coyote.icir.org> > Thanks! Glad you like the patch. We'd love to get nsclick included in > the main Click repository. You're right, most of the patch is related to > namespacing, and is on the clunky side. The CLICK_BEGIN/CLICK_END > solution you suggest sounds fine. It'd definitely be less annoying for > folks creating elements. If you could let me know what needs to be done > to move forward on integrating nsclick into the main Click repository > that would be great. Thanks. I'm going to start merging the patch into the CVS version of Click. One question: Are you wedded to the name 'simclick' (and variants, 'CLICK_SIM', 'CLICKSIM::', etc.)? 'nsclick' (and variants, CLICK_NS, 'CLICK::', etc.) seems more appropriate... E From Michael.Neufeld@Colorado.EDU Tue Aug 6 01:31:45 2002 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Mon, 05 Aug 2002 18:31:45 -0600 Subject: [nsclick-users] integration References: <200208052111.g75LBo010859@coyote.icir.org> Message-ID: <3D4F18F1.8050809@cs.colorado.edu> For the namespacing, "CLICK::" sounds fine, but I'd rather keep the "ns" out of the names. We made a real effort to keep the changes free of code specific to ns-2, even though we're distributing the whole package as "nsclick," and I'd like for it to stay simulator neutral. Internally we've been referring to the distribution as two separate patches - "nsclick" for the ns-2 part, and "simclick" for the Click/simulator part, though that distinction got blurred a bit in the release. -Mike Eddie Kohler wrote: >>Thanks! Glad you like the patch. We'd love to get nsclick included in >>the main Click repository. You're right, most of the patch is related to >>namespacing, and is on the clunky side. The CLICK_BEGIN/CLICK_END >>solution you suggest sounds fine. It'd definitely be less annoying for >>folks creating elements. If you could let me know what needs to be done >>to move forward on integrating nsclick into the main Click repository >>that would be great. Thanks. >> > > I'm going to start merging the patch into the CVS version of Click. > One question: Are you wedded to the name 'simclick' (and variants, > 'CLICK_SIM', 'CLICKSIM::', etc.)? 'nsclick' (and variants, CLICK_NS, > 'CLICK::', etc.) seems more appropriate... > > E > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs.colorado.edu > http://www.cs.colorado.edu/mailman/listinfo/nsclick-users > From kohler@icir.org Tue Aug 6 04:23:09 2002 From: kohler@icir.org (Eddie Kohler) Date: Mon, 05 Aug 2002 20:23:09 -0700 Subject: [nsclick-users] integration In-Reply-To: Message from Michael Neufeld of "Mon, 05 Aug 2002 18:31:45 MDT." <3D4F18F1.8050809@cs.colorado.edu> Message-ID: <200208060323.g763N9012666@coyote.icir.org> > For the namespacing, "CLICK::" sounds fine, but I'd rather keep the "ns" > out of the names. We made a real effort to keep the changes free of code > specific to ns-2, even though we're distributing the whole package as > "nsclick," and I'd like for it to stay simulator neutral. Let me push back on this a bit. Click is distributed with several drivers, userlevel, bsdmodule, linuxmodule. These are different drivers even though most of the code is shared. I would imagine that Click+NS, Click+Whateversim, and so forth, would be separate drivers even though most of the code is shared. Clearly the parts that hook up to simulator innards must differ? I'm advocating that the driver (= the subdirectory of CLICKDIR) be named 'nsclick' or something (just 'ns'? or 'nssim'?), and that there be an 'elements/nsclick' subdirectory. Still, I could be convinced. > Internally > we've been referring to the distribution as two separate patches - > "nsclick" for the ns-2 part, and "simclick" for the Click/simulator > part, though that distinction got blurred a bit in the release. What was the distinction meant to be? Eddie From kohler@icir.org Tue Aug 6 05:24:05 2002 From: kohler@icir.org (Eddie Kohler) Date: Mon, 05 Aug 2002 21:24:05 -0700 Subject: [nsclick-users] simclick / CLICK_DECLS, CLICK_ENDDECLS Message-ID: <200208060424.g764O5012950@coyote.icir.org> Hi all, The rad nsclick work from Colorado , which makes a version of Click that can run inside the NS-2 simulator, is beginning to be integrated into the main Click repository. One change so far that everyone should know about. All declarations and definitions of Click-related C++ code should be wrapped in the macros CLICK_DECLS and CLICK_ENDDECLS. Usually, header files will look like this: #ifndef CLICK_HEADER_HH #define CLICK_HEADER_HH #include #include #include CLICK_DECLS // ... class and function declarations ... CLICK_ENDDECLS #endif and source files will look like this: /* Comment... */ #include #include #include #include "whatever.hh" CLICK_DECLS // ... function and method definitions ... EXPORT_ELEMENT(Whatever) CLICK_ENDDECLS Why? Some Click identifiers unfortunately conflict with identifiers inside NS. When compiling under NS, the CLICK_DECLS and CLICK_ENDDECLS macros will expand into `namespace Click {' and `}', thus shoving all Click code into a separate namespace where it can't hurt anyone. There is no need to use the macros in your elements if you don't plan to support nsclick. There are 4 macros altogether; here is how they expand: Macro Normal drivers Simulator drivers CLICK_DECLS /* */ namespace Click { CLICK_ENDDECLS /* */ } CLICK_USING_DECLS /* */ using namespace Click; CLICK_NAME(n) n Click::n All the necessary code has been checked in to the repository, and all elements have been updated. Eddie Michael Neufeld and others (?) did the nsclick patch. Many thanks! From Michael.Neufeld@Colorado.EDU Tue Aug 6 07:14:05 2002 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Tue, 06 Aug 2002 00:14:05 -0600 Subject: [nsclick-users] integration References: <200208060323.g763N9012666@coyote.icir.org> Message-ID: <3D4F692D.3090409@cs.colorado.edu> OK, I think I see what you're driving at. The code which hooks up with the simulator innards will indeed be different for different simulators. We'd been thinking in terms of keeping the Click interface completely generic and forcing each simulator to adapt to it, but there could easily be cases where that wouldn't make sense. I'm no longer wedded to calling it "simclick." -Mike Eddie Kohler wrote: >>For the namespacing, "CLICK::" sounds fine, but I'd rather keep the "ns" >>out of the names. We made a real effort to keep the changes free of code >>specific to ns-2, even though we're distributing the whole package as >>"nsclick," and I'd like for it to stay simulator neutral. >> > > Let me push back on this a bit. Click is distributed with several drivers, > userlevel, bsdmodule, linuxmodule. These are different drivers even though > most of the code is shared. I would imagine that Click+NS, > Click+Whateversim, and so forth, would be separate drivers even though most > of the code is shared. Clearly the parts that hook up to simulator innards > must differ? > > I'm advocating that the driver (= the subdirectory of CLICKDIR) be named > 'nsclick' or something (just 'ns'? or 'nssim'?), and that there be an > 'elements/nsclick' subdirectory. > > Still, I could be convinced. > > >>Internally >>we've been referring to the distribution as two separate patches - >>"nsclick" for the ns-2 part, and "simclick" for the Click/simulator >>part, though that distinction got blurred a bit in the release. >> > > What was the distinction meant to be? > > Eddie > From kohler@icir.org Tue Aug 6 16:47:23 2002 From: kohler@icir.org (Eddie Kohler) Date: Tue, 06 Aug 2002 08:47:23 -0700 Subject: [nsclick-users] integration In-Reply-To: Message from Michael Neufeld of "Fri, 02 Aug 2002 15:38:58 MDT." <3D4AFBF2.9080301@colorado.edu> Message-ID: <200208061547.g76FlN018042@coyote.icir.org> > If you could let me know what needs to be done > to move forward on integrating nsclick into the main Click repository > that would be great. Thanks. So the Click repository now has optional namespace protection. I'd like some advice on how to proceed. My plan was to create a config-nsclick.h.in, modeled on the current config-userlevel.h.in, and an nsclick/ subdirectory. Although nsclick will be separate from the userlevel 'click' driver, it will share a lot of code. I'm not entirely sure how to represent that. For example, should elements that 'ELEMENT_REQUIRES(userlevel)' be included? Should CLICK_USERLEVEL be defined? I'm currently thinking that (like in your patch) CLICK_USERLEVEL should be defined, but (unlike your patch) 'ELEMENT_REQUIRES(userlevel)' should fail. [People will have to do 'ELEMENT_REQUIRES(userlevel|nsclick)' or something.] Comments? At some point I'd appreciate your guys' help in doing the merge. How can I make it easiest? E From Michael.Neufeld@Colorado.EDU Tue Aug 6 17:16:38 2002 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Tue, 06 Aug 2002 10:16:38 -0600 Subject: [nsclick-users] integration References: <200208061547.g76FlN018042@coyote.icir.org> Message-ID: <3D4FF666.3040608@cs.colorado.edu> That sounds like the right way to go - CLICK_USERLEVEL defined, but ELEMENT_REQUIRES(userlevel) not drag an element into the nsclick build. As far as helping out with the merge, how about giving me write access on the CVS tree? I'm the only one working under the hood on nsclick here at Colorado right now. -Mike Eddie Kohler wrote: >>If you could let me know what needs to be done >>to move forward on integrating nsclick into the main Click repository >>that would be great. Thanks. >> > > So the Click repository now has optional namespace protection. I'd like > some advice on how to proceed. > > My plan was to create a config-nsclick.h.in, modeled on the current > config-userlevel.h.in, and an nsclick/ subdirectory. > > Although nsclick will be separate from the userlevel 'click' driver, it > will share a lot of code. I'm not entirely sure how to represent that. For > example, should elements that 'ELEMENT_REQUIRES(userlevel)' be included? > Should CLICK_USERLEVEL be defined? I'm currently thinking that (like in > your patch) CLICK_USERLEVEL should be defined, but (unlike your patch) > 'ELEMENT_REQUIRES(userlevel)' should fail. [People will have to do > 'ELEMENT_REQUIRES(userlevel|nsclick)' or something.] Comments? > > At some point I'd appreciate your guys' help in doing the merge. How can I > make it easiest? > > E > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs.colorado.edu > http://www.cs.colorado.edu/mailman/listinfo/nsclick-users >