On 15/07/14 18:30, Justin Cormack wrote: > On Tue, Jul 15, 2014 at 4:26 PM, Ian Jackson <[email protected]> > wrote: >>> 2) deciding if we want very simple "builtin" versions of some common >>> configuration utilities, or if we'll always include the full NetBSD >>> binaries >> >> Perhaps we can keep the set utilities small enough that we don't need >> to replicate busybox. > > The problem about having a builtin set is that they are still big > enough to need tests and bugfixes and documentation and so on. If > NetBSD already had a Busybox it might be a different matter.
I was thinking the "builtin" set would be something like the existing netconfig lib (~300 lines of code, plus dhcp) and just some additional C code to call mkdir+mount; something really really simple. >>> 3) deciding if we want applications themselves to handle backgrounding >>> e.g. via daemon(), or limit backgrounding to rc scripts using &, and >>> dealing with whatever problems arise as a result > > Things like dhcp need to background, so need to resolve quite early on. I don't think we'll be using a "userspace" dhcp client in any case. And I don't think backgrounding is a problem. In fact, this more or less does backgrounding already: https://github.com/rumpkernel/rumpuser-xen/blob/master/rumpkern_demo.c#L336-L376 > Another option that just occured to me, as performance of this setup > phase is not critical, might be to use a C interpreter eg > https://code.google.com/p/picoc/ to run the NetBSD utilities... That > then solves the namespacing issues, and allocation etc, obviously > needs hooking into the rump syscalls. Then you just ship (compressed) > source code in a config library. I might try prototyping this. Right, the setup phase is not performance critical, up to a certain definition of "not". That's why remote clients work so nicely for configuration (in userspace). Curious idea, assuming you can find a C interpreter which both has reasonable memory requirements and works. Not sure picoc would work for NetBSD userland utils (which, if nothing else, tend to be C99): https://code.google.com/p/picoc/wiki/DifferencesFromC90 I'm pretty sure if you can get one hooked to libc, rump kernel syscalls will just work. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
