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

[Antti Kantee <pooka@xxxxxx>]

On 15/07/14 15:26, Ian Jackson wrote:
> > 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.
A rump kernel does not use a base fs image, at least unless I 
misunderstood what you meant by base fs image.
For some applications it might be convenient to supply some sort of fs 
image, e.g. the libc calls that thttpd makes requires /etc/services, 
/etc/master.passwd and so forth.  However, let's imagine a 
router/firewall.  There is no true need to have any file system support 
in a rump kernel in that configuration (as in open() will return 
ENOSYS).  Yet, the router needs to be configured somehow.  That's why 
I'd rather supply the configuration information out-of-band.
If I correctly understood what you mean by the xenstore stuff later, you 
are saying that the steps could be embedded, while the data needed by 
those steps could come dynamically from xenstore.
> 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.
Ok, but we still need to execute the actual configuration commands somehow.

> >     builtin_mkdir /etc
> There is no need for the script to be able to mkdir.
Why?  Where will the mountpoint come from?

> >     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.
I have no idea what that means.

Can you elaborate on how that will solve the practical problem of 
"thttpd needs some files in /etc"?
> >     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) ?
Symbol separation is what I referred to with crunchgen/busybox.  I don't 
know about busybox, but at least crunchen does symbol renaming/hiding.
Without going into a lot of detail, a rump kernel has an internal notion 
of a "process", sans a virtual memory space.  I think the original use 
case was debugging the AF_UNIX file descriptor passing code (though 
there are other uses now).  Multiple "processes" can communicate e.g. 
with pipes just like on a regular system.
It's alarming only if you don't know what you're doing.  Obviously if 
you want to lump a ton of processes into a single guest, you should be 
running a full OS.  However, there might be cases where being able to 
run a few just makes things a lot easier to set up.  It's of course a 
different story if we should support it before having any actual use 
cases ...
> > 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.
... yes, that's one option.

> > 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().
My definition of backgrounding here = "rc script" doesn't wait for the 
current process to finish before running the next one.  That works quite 
easily, we just create a thread before we call the application main and 
either join that thread or not.  It might be possible to reach the same 
effect by "guessing" what fork() means for an application, but then 
again it might be better to not guess.
> 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 ?
They don't exist, so I don't know yet ;)

What I do know is that I'd like things to be general enough so that 
whatever infra you build on top of this doesn't have to be changed in 3 
weeks (or forked) when we discover a platform where there is no equivalent.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel