On Sat, Mar 8, 2014 at 1:33 PM, Antti Kantee <[email protected]> wrote: > 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 ...
Maybe, its odd that there were no issues with rumprun, but its not a hugely complicated program to debug... >> 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 ;) Indeed. Too many options. Will look and see if upstream ssl stuff is still using .init. >> 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 ;) It will be a host libc, just not the normal one. I might do some experiments with porting NetBSD libc to Linux, its been done once before after all (Android), and without having to port the syscalls. Or simplify it by statically linking everything carefully. The main reason for using dynamic libraries in the first place was to make symbol conflicts manageable. But the same solution should be possible by carefully static linking in the right way with similar renaming. And possibly custom crt*. Might turn out more fruitful. > > 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. Yes its certainly got some overlap. You could glue it together with a Lua script or a bit of C code. You more or less just need to rename the entry points so there are not too many mains (assuming no other symbol conflicts), then link all the .o files together with libc. You could test out it theory by trying to make a multicall shared lib for rumprun. But the static linking path above could be even closer. > 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. I think its going to take a while so may as well merge shellenv for now. executive is actually more similar than I thought it was going to be (so far) so merging shouldnt be too hard later. Justin ------------------------------------------------------------------------------ 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
