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



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