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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Antti Kantee writes ("Re: some thoughts on appstacks and app-tools"):
> On 15/07/14 15:26, Ian Jackson wrote:
> > 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.

The demo application supplied in rumpuser-xen comes with a pair of ffs
images.  Perhaps that's just because it's doing an fs test ?

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

I see.

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

Yes.

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

If that isn't happening already if you specify "ip=..." in the
appropriate place in the xl domain config file then there is a bug in
something, I think.

> >>     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"?

I mean that the domain config file could say
  disk = [ "vdev=xvda, mountpoint=/etc, target=/path/to/blah.ffs" ]
and libxl would put the mountpoint info in xenstore so something
in the rump kernel Xen environment would pick it up.

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

Busybox is a single application, not a build tool.  I wasn't aware of
crunchgen.  That does sound like it could do the job.

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

Cor.  OK then.

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

I think it would be better to do this ad-hoc in the script language.

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

Yes.

Ian.

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