Re: network bridge configuration for rumprun
- From: Antti Kantee <pooka@xxxxxx>
- To: anil@xxxxxxxxxx, Martin Lucina <martin@xxxxxxxxxx>
- Date: Mon, 29 Jun 2015 14:01:20 +0000
[warning: this mail is incoherent rambling. don't think and write!]
On 29/06/15 09:20, Anil Madhavapeddy wrote:
You're right! I guess the problem with separating them is that the
"inside" and "outside" configurations become intertwined with non-trivial
topologies fairly soon. Still, reusing existing libraries for internal
setups does make sense where possible...
My mail was a bit unclear. Yes, I'm trying to figure out the guest-side
configuration in a way where it would a) work for bridging inside the
rump kernel so that you could run the equivalent of the commands from
the URL I cited in the initial mail b) be general enough to usable for
other things too c) not be so complicated to use that I can't use it.
So, it's not a hard problem like intertwining inside and outside network
config, but it's one that needs thought nonetheless.
Notably, a custom "executable" and a custom "json handler" (1 & 2) are
equivalent, with the exception that the executable is called with an
argv[] and the json handler/interpreter is called with the json script.
Also, config handlers would (probably) always be called before the
first main(). So they are really just two different ways to call a
short-term main().
I'd go for the custom json handler approach for now, an least as an
experiment to see how it works, except I can't figure out how to work
the handlers into the build process. In a pinch, they could be baked as
regular executables with the registration call in
__attribute__((constructor)) (to make it run before rumprun_config())
and an empty main() (because it's not needed except to make things
link), but that seems kludgy, especially because at least currently it
would produce the "foobar main called/exited" console prints. Then
again, if rumpbake accepted some sort of -d <datafile> flag to indicate
that that particular linkable does not contain a main(), it could be
used to link in all other types of data crap too, like file system images.
But now everything is again starting to look very complicated for the
purpose of doing one "bridge add" function call.
Actually, if there were a way for an executable to say "I want to run in
the background" after it was called (a bit like daemon()), things would
just work without any infrastructure changes, apart of course from
making RUNMAINS() launch programs in series instead of in parallel like
now. That should be easy to implement quickly, at least if it weren't
currently sunny outside.
Other related posts:
