Re: [Qemu-devel] [PATCH 3/4] virtio-console: Add support for multiple ports for generic guest-host communication

[Amit Shah]

On (Wed) Sep 23 2009 [13:20:33], Gerd Hoffmann wrote:
>
>>>> +    char *name;
>>>> +
>>>> +    QTAILQ_HEAD(, VirtIOConsolePortBuffer) unflushed_buffer_head;
>>>> +
>>>> +    bool guest_connected;
>>>> +    bool host_connected;
>>>> +};
>>>
>>> Sticking a pointer to VirtConPortDeviceInfo here is probably handy.
>>> More consistent naming please.
>>
>> Consistent naming for what?
>
> The structs.  Pick a prefix (say VirtCon) and stick with that.  Then for  
> the bus implementation:
>
> VirtConBus         (fine)
> VirtConPort        (VirtIOConsolePort now)
> VirtConPortInfo    (VirtConPortDeviceInfo now)

Yeah; I've not renamed the structs yet.

> The console port driver could name its state info this way:
>
> VirtConPortConsole (doesn't exist right now it seems ...).

You're actually suggesting to split everything -- a console (in the
current sense) is a different device and a port (the new vmchannels) are
different devices. Right?

>>> You should be able to move the port driver(s) to a separate source file
>>> without much trouble.  Only the port driver should deal with a chardev.
>>
>> Oh OK; maybe I understand what you're saying about the chardevs now.
>>
>>> The virtio-console core should not care at all how the data is piped to
>>> the (host side) users.  It just drives the ring, forwards events,
>>> accepts data for the guest (via helper function), passes on data from
>>> the guest (via callback in VirtConPortDeviceInfo).
>>
>> Hm, let me think over this.
>
> A port driver should look roughly like the attached one.  That one does  
> something completely different:  Implement a watchdog ;)  Warning:  
> didn't even compile it.
>
> The console port driver would have the chardev instead of the timer in  
> the driver state struct and would basically forward the data between the  
> port and the chardev.

Thanks; parsing all this..

                Amit