On Sat, Oct 25, 2014 at 1:26 PM, Antti Kantee <[email protected]> wrote: > 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 ;)
He just wanted PF_UNIX to be host in effect, ie a host replacement for that socket family. I can see quite a lot of rump programs where this might be useful, as most programs dont use ipc between threads. Obviously it might not support sending fds or credentials, and you would not have an easy way to unlink a named socket, but might still work ok. Justin ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
