From: Anthony Liguori <aliguori@us.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Amit Shah <amit.shah@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@linux-foundation.org,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v10 1/1] virtio_console: Add support for multiple ports for generic guest and host communication
Date: Fri, 06 Nov 2009 08:32:05 -0600 [thread overview]
Message-ID: <4AF43365.2030208@us.ibm.com> (raw)
In-Reply-To: <200911061512.40413.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
>> Fundamentally speaking, right now, virtio-console is a single stream
>> that acts as an interactive terminal. What we're looking to add here is
>> to support multiple terminals that can be enumerated in a rationale way.
>>
>
> Right, that is a point where I disagree. The original purpose and intent of the
> multiple port thing was to have a generic guest/host comm channels and *NOT* to
> have multiple console devices. Having multiple console devices is just a fall-
> out of the current implementation.
>
This is part of what makes this series so difficult. As a generic
guest/host communications channel, this series does not at all meet
reasonable expectations. It makes no attempt to deal with things like
live migration. It can at best be described as a hack.
The whole thing's a mess because it's never been thought through
properly which is probably because the actual consumer of it has not
been released publicly.
I've always advocated that this use case would be better served as a
_userspace_ interface that implements a protocol on top of an arbitrary
transport. It could be a network socket, a virtio device (even
virtio-console unmodified), a real serial device, etc.
You can do multiplexing, connect/disconnect notification, etc. all as
elements of a streaming protocol. Throwing all of these channel
semantics coupled tightly with the transport and then trying to make a
kernel interface be what's the supported user interface is really just
asking for trouble.
--
Regards,
Anthony Liguori
next prev parent reply other threads:[~2009-11-06 14:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 16:38 [PATCH v10 0/1] virtio-console: Support for generic ports and multiple consoles Amit Shah
2009-11-03 16:38 ` [PATCH v10 1/1] virtio_console: Add support for multiple ports for generic guest and host communication Amit Shah
2009-11-06 7:10 ` Rusty Russell
2009-11-06 8:00 ` Christian Borntraeger
2009-11-06 13:00 ` Anthony Liguori
2009-11-06 14:12 ` Christian Borntraeger
2009-11-06 14:32 ` Anthony Liguori [this message]
2009-11-09 12:08 ` Amit Shah
2009-11-10 2:19 ` Rusty Russell
2009-11-06 7:43 ` Christian Borntraeger
2009-11-09 12:09 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF43365.2030208@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=amit.shah@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox