Re: [Xen-devel] some thoughts on appstacks and app-tools

[Antti Kantee <pooka@xxxxxx>]

On 15/07/14 18:30, Justin Cormack wrote:
> On Tue, Jul 15, 2014 at 4:26 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel