On 08/03/14 11:32, Justin Cormack wrote: > I made a new branch of rumprun called "executive" that builds the > NetBSD userland tools as standalone binaries rather than dlopening > them. It partially works, but there are some issues. > > The basic networking stuff, like ping, ifconfig seems to work fine. > > For some odd reason ls does not return anything, so there is an odd > bug there. Possibly something to do with readwrite wrapper? Shouldn't > be too hard to debug.
Maybe there's something wrong with fts? Just guessing; fts is usually a source of pain ... > The programs that use crypto (eg npfctl) are segfaulting as they use > the environment before my initialiser sets it up - in _init. This is > fixable by several possible methods, eg shift it to use constructor > instead, or remove all the netbsd environ stuff from libc and use host > environ instead, or fix up the NetBSD init process. I know that feeling ;) > Which leads to another possible option, which is to link rumpuser > statically with an implementation of the host syscalls it uses so it > does not need host libc, and then construct a wierd hybrid libc to run > NetBSD code, which is basically NetBSD libc except for certain host > parts, such as the dynamic linker. On NetBSD that should be quite > simple, on Linux maybe less so. Perhaps you could even run the NetBSD > linker on Linux though? Dunno, a userspace binary without a host libc sounds complicated. But I think I said that about rumprun too before you went ahead and did it, so ignore me if relevant ;) > Overall it would be nicer than dlopen, and probably more portable (the > dlopen solution does require some oddness, hence not working on > NetBSD, or indeed Musl), but there are issues... Given that dl*() is not available in use cases like rumpkernels-on-Xen, does the work on the "executive" branch have any synergies with producing "crunchgen"-like results? Simple standalone application stacks could link a few necessary tools like mount and ifconfig into the same bunch with the kernel drivers, and have a simple list of commands to run as the rc "script". E.g. in the case of Xen they could even perhaps be passed as a boot parameter. Also, do you have plans to finish and merge the executive branch any time soon, or should I go ahead and merge the "shellenv" branch and wrappers as the current solution? Ideally, from a user pov, nothing will change if we move between "shellenv" and "executive", but there's probably a few Makefile conflicts. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
