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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

(CCing xen-devel.)

Antti Kantee writes ("some thoughts on appstacks and app-tools"):
> I finished playing around a bit with Ian's rumpxen/app-tools and, to 
> pick some arbitrary application, thttpd.  I could download thttpd, 
> configure and make it with app-tools and run the resulting binary as a 
> Xen guest.  No source editing or ad-hoc build stunts were required. 
> That's a truly awesome result!

:-).

> What currently isn't addressed is that applications like thttpd need 
> some base configuration, like a network configuration and maybe the 
> mounting of file system images.  I hacked these configuration steps into 
> callmain.c.  However, the configuration problem shouldn't be very 
> difficult to address properly.

Right.

> Currently, the "extra" parameter of the domain_config takes the command 
> line arguments, e.g. for thttpd:
>    extra = "-u thereisnoroot -D -d /etc"
> (/etc is the only directory that contains some files ... I was lazy ;)
> 
> I'm thinking that instead we'd want it to contain some sort of an 
> attempt at an rc script.  If we do specification-by-example, the 
> following could work for thttpd (starts two instances of thttpd for 
> demonstration purposes):

I think that it would be better to deal with this by providing the
script in the base fs image.  That's a more suitable format for
conveying something extended like one of these scripts.  It also
preserves the distinction between "out of band" environmental
information like the filesystem etc., and the executable and its
command line arguments.

Looking at it this way also enables us to do away with several of
these steps:

> extra =
>    "builtin_ifconfig xenif0 create
>    builtin_ifconfig xenif0 <address>

I think this information is already available via xenstore.

>    builtin_mkdir /etc

There is no need for the script to be able to mkdir.

>    builtin_mount ffs /blk1 /etc

We could perhaps provide a mount point in xenstore along with the
rest of the pv block device control plane info.

>    thttpd -u thereisnoroot -D -d /etc &
>    thttpd -u thereisnoroot -D -p 8080 -d /anotherdir"

This notion of having multiple processes is quite alarming.  There
obviously won't be any memory protection between them, but also: how
will their symbol namespaces be separated ?  Is it intended that they
would be able to communicate via some kind of IPC (eg pipes or AF_UNIX
sockets) ?

> 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.

> 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

Clearly applications can't background themselves (whatever that means)
because they can't call fork().

> Of course, this whole mail isn't really specific to Xen, and I'd 
> eventually like to see things work the same way on all platforms.  But 
> we need at least one working platform as the first step ;)

Yes.

Of course I appreciate that some of the xenstore-based answers I give
above are perhaps less useful to other platforms, but perhaps they
have something equivalent ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel