Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add

[Luiz Capitulino]

On Fri, 26 Mar 2010 20:13:09 +0530
Amit Shah <address@hidden> wrote:

> On (Fri) Mar 26 2010 [11:29:03], Luiz Capitulino wrote:
> > On Fri, 26 Mar 2010 18:56:20 +0530
> > Amit Shah <address@hidden> wrote:
> > 
> > > On (Fri) Mar 26 2010 [10:14:02], Luiz Capitulino wrote:
> > > > > > > +
> > > > > > > +VIRTIO_SERIAL
> > > > > > > +-------------
> > > > > > 
> > > > > >  It should be VIRTIO_SERIAL_ADD.
> > > > > 
> > > > > What about other events that VIRTIO_SERIAL generates?
> > > > 
> > > >  We don't address this problem currently, maybe an integration with qdev
> > > > will do, but I have to think more about it.
> > > 
> > > So should I just keep it as VIRTIO_SERIAL for now? With new events also
> > > riding on this one?
> > 
> >  I don't like this because with the current events code this will lead
> > to confusion, as you're using a single event to notify different things.
> > 
> >  My suggestion for the immediate term is to do what we have been doing so
> > far, ie. call it VIRTIO_SERIAL_ADD. Worst case here is: we add a new way
> > to group events which requires a new VIRTIO_SERIAL event, in this case we
> > could emit both, the new VIRTIO_SERIAL and the old VIRTIO_SERIAL_ADD. The
> > latter would be deprecated too.
> 
> I've no problem doing it either way - whatever you prefer is fine.
> 
> BTW these are two distinct events already - failure in initialising a
> device and failure in initialising a port. Do you think these should be
> separate as well?

 That depends on what you want clients to know/do about it.

 Can ports and devices be added and work independently of each other?
Why is it relevant for a client to know that a _device_ has failed to
initialize?

 If clients connect to a port and all they need to know is "Sorry, but
that port won't be available", then you don't even need to have a port/device
distinction in the event.

 Also note that events can be improved to include more information later,
if needed. So, the best approach is to include as less information as
possible (given that it satisfies current client needs, of course).

> >  Or, if you can wait I can _try_ to solve this problem next week, although
> > I have no idea how hard this is going to be.
> 
> I think it's cleaner to club everything; but basically I'll go with
> whatever you say. I've no problem waiting.

 It's definitely needed to group events some way, we just have to
find a good way to do it. Having each subsystem doing it its own way
is not what we want because of protocol consistency and related
problems.