On 21/10/15 14:07, Martin Lucina wrote:
Okay, so the minimal required steps to launch a rumprun Xen domain are:
1) xl create /dev/null -p kernel=\"wopr.bin\" name=\"wopr\"
(Quoting required, unless you want to create a configuration file)
2) xenstore-write "/local/domain/$(xl domid wopr)/rumprun/cfg" "$(cat
wopr.json)"
3) xl unpause wopr
If you want to do the equivalent of "rumprun -i", i.e. launch a domain and
get its output in a single step, you have to additionally do:
2a) *In a different window* run xl console wopr
Now, I don't understand how, with the proposed syntax/abstraction you get
from
rumprun-launch xl [-c cfg1 -c cfg2 ...] backend params
to the above steps. rumprun-launch now just sees opaque "backend params",
therefor it's *impossible* for it to create the domain in step 1) as it
doesn't have the information required (name, kernel).
step 1: "$@" -p name=wopr. steps 2-n as above.
No different from requiring in the qemu case that the user doesn't pass
his/her own -append or use the [disk image] feature. Don't make things
difficult by trying to reach some imaginary purity which doesn't exist
(see below).
There are obviously some restrictions on the options that can be given to
the backend tool if the user expects things to work. It's going to be that
way with or without a convenience tool.
...? I thought the whole point of removing the rumprun tool was to remove
all such restrictions.
You cannot remove *all* restrictions. Very simple example: you need to
run the right binary. Another very simple example: you need to
configure the right number of network interfaces. The user still has to
give the right parameters, there's no way around it.
The point of getting rid of the rumprun tool is to enable the user to
actually pass the right guest parameters.
I never experienced any problem with e.g. -p or -D with rumprun. Do you
disagree?
Unfortunately, with the proposed scope of the tool, we can't write to
Xenstore, since this requires the
create-domain-as-paused-then-write-to-xenstore dance.
Can you elaborate what "scope of the tool" means here?
You write in the root of this thread:
...having a mostly transparent launch tool (wrt. to the
virtualization backend), but hiding details on how the config is passed to the
guest...
So the scope is just passing config to the guest, and nothing else. If we
remove the need to pass config to the guest *at launch time*, problem goes
away and no special launch tool is needed at all.
The problem it was trying to solve was developers doing quick iteration.
Remember, *you* were concerned about that developer convenience factor
going away. If now two weeks later nobody is interested in iteration
anymore then it makes complete sense to not have such a tool. If so,
the thing that makes *the problem* go away is the attitude change.
Shifting goal posts is a different way of reaching the goal (and
sometimes a completely valid one). In this case shifting the posts
would probably simplify a lot of things, like I already wrote in the
rumprun-rumpbake-axis thread.
Here's the relevant mail, if someone wants to refresh their memory:
https://www.freelists.org/post/rumpkernel-users/fixing-the-rumpbakerumprun-axis,4
So does anyone care about the "quick iteration" going away? (I don't)
