On 02/24/2011 07:25 PM, Anthony Liguori wrote:
Is it really necessary? What's blocking us from initializing
chardevs early?
Well....
We initialize all chardevs at once right now and what set of chardevs
there are depends on the machine (by the way defaults are applied).
You could initialize chardevs in two stages although that requires
quite a bit of additional complexity.
We could initialize chardevs on demand - that should resolve any
dependencies?
It would be a pity to divorce the monitor from chardevs, they're
really flexible.
Couple considerations:
1) chardevs don't support multiple simultaneous connections. I view
this as a blocker for QMP.
What do you mean by that? Something like ,server which keeps on
listening after it a connection is established?
2) Because chardevs don't support multiple connections, we can't
reasonably hook on things like connect/disconnect which means that
fd's sent via SCM_RIGHTs have to be handled in a very special way. By
going outside of the chardev layer, we can let fd's via SCM_RIGHTS
queue up naturally and have getfd/setfd refer to the fd at the top of
the queue. It makes it quite a bit easier to work with (I believe
Daniel had actually requested this a while ago).
I really don't follow... what's the connection between SCM_RIGHTS and
multiple connections?
3) By treating QMP as a special case, we don't have to treat chardevs
overall as a special case. This feels more right to me although I
can't say I have a strong opinion formed yet.
2) Make qemu_machine_init() take no parameters and just reference
global state.
3) Teach all QMP functions to behave themselves if called before
qemu_machine_init()
4) Introduce QMP function to call qemu_machine_init()
An alternative is to remove all guest-visible content from
qemu_machine_init(). So machine->init() would take no parameters and
only build the static devices (power supply?). Everything else would
be hot-plugged (perhaps some would fail if the machine was started -
cold-plug only).
All that qemu_machine_init() is is guest-visible content. That's the
point of refactoring this.
Sorry, poorly phrased. Configurable guest visible content.
(6) can be started right now. (1) comes with the QAPI merge. (2)
is pretty easy to do after applying this patch. (3) is probably
something that can be done shortly after (1). (4) and (5) really
require everything but (6) to be in place before we can meaningful
do it.
I think we can lay out much of the ground work for this in 0.15 and
I think we can have a total conversion realistically for 0.16. That
means that by EOY, we could invoke QEMU with no options and do
everything through QMP.
It's something that I've agitated for a long while, but when I see
all the work needed, I'm not sure it's cost effective.
There's a lot of secondary benefits that come from doing this. QMP
becomes a much stronger interface. A lot of operations that right now
are only specifiable by the command line become dynamic which
mitigates reboots in the long term.
Only the hot-pluggable ones.
It also lays the ground work for a fully decoupled device model
whereas the only interface between the devices and the outside world
is a subset of QMP (think seccomp()).
Whether creating a machine with no command line options is high value
is probably irrelevant. I think we want to go in this direction
regardless.
I agree it's a good thing.
--
error compiling committee.c: too many arguments to function
