On 25/10/14 12:08, Justin Cormack wrote: > On Sat, Oct 25, 2014 at 12:55 PM, Antti Kantee <[email protected]> wrote: >>> IMO they (librumpkern_sys_foo, rumprun-*) serve different use cases. If I >>> understand you correctly the rumprun-* model serves when you want to run >>> unmodified applications using the entire rump kernel stack. > > I think the use case of wanting to talk to rump stack and native > kernel stack is as Antti says "expert" but there are use cases, eg I > was talking just the other day to someone who was interested in having > an application that talked to the network purely via rump but talked > via sockets to other code on the box. > > There are namespacing issues but I think it is possible to make > something where this is not too horrible, as this is essentially what > rumprun is doing internally. I hope to have a proof of concept in a > while...
That sounds almost like what rumpnet_sockin already does. It's not quite the same, though, as sockin is meant to be a transparent drop-in for a full networking stack in a rump kernel, and registers itself as PF_INET/PF_INET6. You can't have many implementation providing the same protocol family, so sockin is currently mutually exclusive with netinet. One could probably add PF_HOST or something like that to sockin for the explicitly programmed case, and, assuming I correctly understood what is wanted, be done with it very quickly. So just in case the above was hard-to-read, _A DIAGRAM_: PF_INET: app -> syscall -> socket -> netinet -> interface -> hypercall or hw PF_HOST: app -> syscall -> socket -> sockin/host -> hypercall (host socket) I'd still call that an expert scenario ;) ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
