[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.