Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop

[Avi Kivity]

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