Bugzilla – Bug 720
TapBridge creation fails from a script outside the ns3 tree
Last modified: 2010-02-05 13:26:50 EST
A script running from outside the ns tree that attempts to create a TapBridge throws the following error: Parent process Child process TapBridge::FindCreator(): Couldn't find creator TapBridge::CreateTap(): socket creator exited abnormally Segmentation fault The cause seems to be that when trying to execl "tap-creator", we search only in the build tree. This is in the FindCreator function in devices/tap-bridge.cc. Paths to search are in-fact hard-coded, which seems unclean. Example: locations.push_back ("./build/optimized/src/devices/tap-bridge/"); The following change enables searching for tap-creator in $PATH. It uses execlp instead of execl and does not call FindCreator. This enables a script using TapBridge to work from anywhere if tap-creator is in the path. Inside the ns3 tree, one should probably have waf --run modify paths appropriately. --- tap-bridge-orig.cc 2009-10-14 14:30:38.000000000 -0400 +++ tap-bridge.cc 2009-10-14 14:30:54.000000000 -0400 @@ -432,8 +432,8 @@ // // Execute the socket creation process image. // - status = ::execl (FindCreator ("tap-creator").c_str (), - FindCreator ("tap-creator").c_str (), // argv[0] (filename) + status = ::execlp ("tap-creator", + "tap-creator", // argv[0] (filename) ossDeviceName.str ().c_str (), // argv[1] (-d<device name>) ossGateway.str ().c_str (), // argv[2] (-g<gateway>) ossIp.str ().c_str (), // argv[3] (-i<IP address>)
The reason it works that way is to support multiple builds of different versions. For example, I currently have 24 different builds of different versions of ns-3 on my primary machine. This wouldn't work very well if the code looked into $PATH for the creator.
I see how it makes testing convenient for you. But I am using ns3 in a fairly normal way, i.e., importing it into my python package which lives in another repository. It is not practical to have the entire ns3 tree in there. I see no way to make my setup work without patching ns3 in some way. Perhaps, there is a way make both of us happy. Here are some suggestions: 1) Make tap-creator a separate program living in ns3 top-level and built separately. Then have ns3's 'waf configure' find it and pass it to the current build. After all, tap-creator is really a convenience utility, mostly unrelated to ns3. 2) Alternatively, waf --run (and/or --pyrun) could find the tap-creator for the version being built and put it in the path. ns3 is a great project, a pleasant surprise for an erstwhile ns2 user like myself. Thanks for doing it so well. I would love to see it packaged for the major linux and bsd distributions in the near future. And hardcoded things like this do get in the way. In fact, the whole "running everything through waf" model bothers me a bit. -vikas
(In reply to comment #1) > The reason it works that way is to support multiple builds of different > versions. For example, I currently have 24 different builds of different > versions of ns-3 on my primary machine. > > This wouldn't work very well if the code looked into $PATH for the creator. I suppose, it will work just fine, if you run your scripts through "./waf --run" or "./waf shell", which can easily prepend $PATH with something like "/home/user/repos/ns-3-dev-24/build/debug/src/devices/tap-bridge". Another way is to enable FindCreator to search in $PATH locations before giving up. Hardcoding some strange paths into sources is not a good way. EmuNetDevice has the same problem.
Created attachment 659 [details] Look for {tap,emu-sock}-creator in $PATH. 1) use execlp instead of execl 2) remove FindCreator() functions 3) prepend $PATH with "build/debug/src/devices/{tap-bridge,emu}" (for debug builds) 4) prepend $PATH in spawned processes environment with bld.env['PATH']. This patch uses hardcoded paths like "src/devices/tap-bridge" and "src/devices/emu" in wscripts, but this can be improved if needed.
+1. Craig needs to ack this. assigning to him.
I have a hard time with putting this in PATH. I would prefer to see this work similarly to NS3_MODULE_PATH. For example, if you "waf run" something an environment variable could be set up that points to a common place for subordinate executables to live. Like, NS3_EXECUTABLE_PATH = /home/craigdo/blah/yadda/ns-3-dev/bin Then tap or emu or some other similar thing yet to be built could just look there. If you don't "waf run" you can "waf shell" which would then set up NS3_MODULE_PATH and NS3_EXECUTABLE_PATH. Then you can cd wherever you want.
Created attachment 741 [details] Rewritten with NS3_EXECUTABLE_PATH variable
(In reply to comment #6) > I have a hard time with putting this in PATH. I would prefer to see this work > similarly to NS3_MODULE_PATH. > > For example, if you "waf run" something an environment variable could be set up > that points to a common place for subordinate executables to live. Like, > > NS3_EXECUTABLE_PATH = /home/craigdo/blah/yadda/ns-3-dev/bin > > Then tap or emu or some other similar thing yet to be built could just look > there. > > If you don't "waf run" you can "waf shell" which would then set up > NS3_MODULE_PATH and NS3_EXECUTABLE_PATH. Then you can cd wherever you want. I've attached modified version of a previous patch. The changes from the first patch are: 1) Introduced NS3_EXECUTABLE_PATH variable and made it very similar to NS3_MODULE_PATH 2) NS3_EXECUTABLE_PATH appending for {emu,tab-bridge}-creator is moved from build phase to configure phase 3) The patch is split into 2 changesets, because the 1) change is generic while the 2) is bug specific
(In reply to comment #8) > 3) The patch is split into 2 changesets, because the 1) change is generic while > the 2) is bug specific Maybe I was unclear: s/the 1) change/introducing NS3_EXECUTABLE_PATH/ s/the 2)/looking for creators in PATH/
changeset c85cb9b073a0