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

[Antti Kantee <pooka@xxxxxx>]

On 15/07/14 16:28, Ian Jackson wrote:
> 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 ?
Yes.  I think test.ffs predates libc support, and it was just a simple 
way of showing that the rump kernel guest can really use the kernel file 
system driver.  It's a rather weak demo these days, should probably 
remove it.
etc.ffs is there for reasons explained in the previous mail.  The 
necessary /etc files for getservent() et al could be generated 
otherwise, but it was just simpler to supply a file system image for 
that purpose and get the httpd demo rolling.
In fact, you can run a rump kernel guest just fine without specifying a 
single "disk" or "vif" line in the domain config.  I used to often omit 
I/O devices for testing, since it tends to spin up the guest domain 
faster (doesn't run qemu?).  That way you of course can't mount external 
disk images or access the network, but not all testing needs those 
capabilities.
> > > > 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.
At least one bug is that I wasn't aware that it should happen ;)

Is the expected format documented somewhere?  E.g. ipv4 vs. ipv6, 
default router, dhcp, etc?  xl-network-configuration is a little vague 
about it.
That said, ip= it might be good enough for a simple configuration, but 
it will most likely fall short for e.g. a router/firewall.  I'm not sure 
if an "rc script" should inline that type of configuration data, but if 
that's literally all that the rc script doing, might be appropriate to 
cut down the number of configuration files by allowing inlining.  <== 
thinking out loud
> 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.
Sounds good.  Can we pass arbitrary parameters a la fstab?

> > 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.
Ok.  They are usually mentioned together, so I thought busybox was the 
Linux equivalent of crunchgen, kinda in the lsof(8) vs. fstat(1) sense. 
 Standing corrected.
> > > 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.
You're probably right ... at least until we run into the first 
application that completely refuses to succumb to being backgrounded 
like that.  But it sounds like a hurdle that can be crossed if it 
appears at all.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel