Open craig-riecke opened 8 years ago
Just compile with make install
. Then openflow
should be on the PATH.
Yeah, that would work ... if a monolithic app looked on the PATH. It doesn't. It only looks for openflow
or openflow.native
in the same directory as the executable you're running. The logic is in Frenetic_OpenFlow0x01_Controller.ml line 30.
It should be an easy fix.
Wait. Why do we have two executables anyway? It seems like it only causes confusion with PATH, etc. I think we should run frenetic.native twice (or n times) with different command-line arguments -- once for the high-level controller and once for the low-level controller. The first one could even fork() to create the other copies so we only need one invocation at the command line.
-N
On Tue, Jun 21, 2016 at 3:03 PM, Craig Riecke notifications@github.com wrote:
Yeah, that would work ... if a monolithic app looked on the PATH. It doesn't. It only looks for openflow or openflow.native in the same directory as the executable you're running. The logic is in Frenetic_OpenFlow0x01_Controller.ml line 30.
It should be an easy fix.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/frenetic-lang/frenetic/issues/508#issuecomment-227539142, or mute the thread https://github.com/notifications/unsubscribe/ABwi0gzfkXPGqw5W4reJteIBYXDfm3z8ks5qODV-gaJpZM4I6sgQ .
@jnfoster We do use one invocation - the frenetic.native binary (or the monolithic app) starts the openflow.native binary through Process.create. It would be great to use fork instead, but we can't because of Async. Or rather, the Async scheduler - we start it up to handle some deferred's and ivar's (they are needed for other parts of Frenetic) prior to creating the openflow.native process. If we forked, the Async scheduler would be totally mucked up in the child process, ref: https://groups.google.com/forum/#!topic/ocaml-core/an6dwjN_yCY
We could do one binary, but a monolithic app would have the same problem finding frenetic.native - Process.create doesn't look through the PATH by default. Unless maybe it started another copy of itself...
good point...
Not sure which point is a good one.
It would still be my preference to have a single binary -- it eliminates complexity in several places.
-N
On Wed, Jun 22, 2016 at 1:53 PM, Steffen Smolka notifications@github.com wrote:
good point...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/frenetic-lang/frenetic/issues/508#issuecomment-227824334, or mute the thread https://github.com/notifications/unsubscribe/ABwi0jFm3fmulD6ULWn7rr9KTLY0sEq7ks5qOXZ_gaJpZM4I6sgQ .
"Good point" was referring to Nate's comment. Having two binaries trying to find each other sounds like it will break very easily. There must be a way around it.
Craig, under the link you posted they mention reset_in_forked_process
. Can't we use that?
When Frenetic runs with http-controller, it starts up the separate executable
openflow.native
as a subprocess. This works fine for programming in Python or REST. However, it doesn't work well when building a monolithic OCaml Frenetic app (basically the Northbound app is compiled in with Frenetic itself).Currently the workaround is to create a symbolic link to
openflow.native
in the same directory as the monolithic app executable, as show in the Wiki. It'd be nice not to require that.