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.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
