Hi, Nice work towards solving ..
On 14/08/15 13:40, Kevin Boulain wrote:
Actually, multiples variables corresponding to options that will be later passed to qemu-system-* commands are generated by rumprun and the final command is generated from that. One of the problems that I encountered is sometimes, depending on the passed filenames or options, the command generation can break.
.. a problem.
However to allow the use of xargs, and this is the reason of this post on the mailing list, the rumprun cli changes from: rumprun [script args] PLATFORM [guest args] APP [ -- ] [app args] to: rumprun [script args] PLATFORM APP [guest args] [ -- ] [app args]
Impressive shell hackery, but generally we should figure out what external interfaces we want, and then figure out how to implement them. If the current tools don't let us build what we want, we should first think if we can use better tools.
So, if folks think that the new usage is better than the old usage, we should go for it. If not, or even if ambivalent, we should seriously consider if we can find better tools which allow us to to do what we want, and evaluate the cost of moving from /bin/sh to that tool.
Finally, I would like to discuss the possibility to auto-detect the platform from the application. As you could see from the discussion on issue 40, adding special information to the ELF binary could allow rumprun to defaults to using QEMU for the hardware platform or Xen for the Xen platform by default (see the discussed implementation in the issue 40 that is not part of this diff here: https://github.com/rumpkernel/rumprun/commit/e8e6bb7ccf8cd12cff26d7b92bb3cc8391050272, note that instead of defsym ELF notes should be used, but this illustrate the proposition). A downside being that if KVM wanted to be used (or another platform that could be added in the future like VirtualBox), the platform should be specified explicitly with an option to rumprun (which will roughly be the same as today). The final rumprun cli could look like this: rumprun [script args] [ -- ] APP [guest args] [ -- ] [app args]
I think a binary should contain information on what it was built for. However, since we have quite a few ways to rumprun hw binaries, I'm not sold that we should pick one default in the UI.
Like I've been saying for a while, the rumpbake-rumprun axis needs a radical out-of-the-box rethinking. Hopefully there will be sunny+warm days here the coming week, and I can take a really really long bikeride with my trusty notebook and pen to work on the issue.
