All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports
Date: Wed, 30 Sep 2009 20:39:34 +0200	[thread overview]
Message-ID: <4AC3A5E6.6070703@redhat.com> (raw)
In-Reply-To: <20090930155534.GB1011@amit-x200.redhat.com>

> BTW the kernel too doesn't support multiple devices so far.

Needs fixing too ;)

>> I'd suggest to look what do do when another user which wants buffering
>> comes along.  Might be the requirements are different, so it wouldn't
>> work anyway.
>>
>> Also when you pass around pointers to VirtConPortBuffer the port drivers
>> can implement buffering very easily.
>
> It will mostly be duplicated. Right now, I pass on an entire message as
> was passed on by the kernel in one write() request. If I start passing
> around buffers, it'll be incomplete messages (eg, an 8K write request in
> the kernel will be split in two buffers of 4K each -- or three buffers
> with the last one containing a few bytes). I don't think I want the ports
> to worry about that. The ports should just get the entire message.

Sure.  I think there is a misunderstanding here.  I meant only the 
"buffer messages when unconnected" thing.  Reassembling the messages in 
the core and forward only complete messages to the ports is fine.

> So I don't think I want to expose the buffers to individual devices.

My idea was to pass the (reassembled) message to the port drivers in a 
form they can just stick into a list without memcpy()ing the message in 
case they want to keep it.  Maybe to buffer it because the chardev is 
unconnected.  Maybe just keep the most recent message because it 
contains some kind of guest status.

VirtConPortBuffer looked like it could do the job.  Well, not perfectly, 
it has extra status which is needed only by the core for reassembling 
messages.

>> They are handled differently though.  I think console will not do any
>> buffering at all, whereas serial-port provides the option to do
>> buffering.
>
> But the buffering is independent of the char drivers.

See above ;)

> Basically I've now dropped the old -virtioconsole argument.
>
> So one has to do:
>
> -device virtio-console-pci -device virtioconsole ...
>
> to start a console.

If you do '-device virtio-console-pci -device virtio-port' (i.e. no 
console) and boot a old guest kernel which expects a (single) console 
being there, what will happen?

cheers,
   Gerd

  reply	other threads:[~2009-09-30 18:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29 12:04 [Qemu-devel] virtio-console-bus, multiport, virtio-console-port Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 1/6] char: Emit 'OPENED' events on char device open Amit Shah
2009-09-29 12:04   ` [Qemu-devel] [PATCH 2/6] qdev: add string property Amit Shah
2009-09-29 12:04     ` [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Amit Shah
2009-09-29 12:04       ` [Qemu-devel] [PATCH 4/6] virtio-console-port: Add a new device on the virtio-console-bus for generic host-guest communication Amit Shah
2009-09-29 12:04         ` [Qemu-devel] [PATCH 5/6] vnc: add a is_vnc_active() helper Amit Shah
2009-09-29 12:04           ` [Qemu-devel] [PATCH 6/6] vnc: Add a virtio-console-bus device to send / receive guest clipboard Amit Shah
2009-09-29 18:13             ` Gerd Hoffmann
2009-09-30  4:50               ` Amit Shah
2009-09-29 18:08         ` [Qemu-devel] [PATCH 4/6] virtio-console-port: Add a new device on the virtio-console-bus for generic host-guest communication Gerd Hoffmann
2009-09-30  8:09           ` Nathan Baum
2009-09-29 18:04       ` [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Gerd Hoffmann
2009-09-30  4:47         ` Amit Shah
2009-09-30  8:59           ` Gerd Hoffmann
2009-09-30 15:55             ` Amit Shah
2009-09-30 18:39               ` Gerd Hoffmann [this message]
2009-10-01  4:54                 ` Amit Shah
2009-10-01  8:38                   ` Gerd Hoffmann
2009-10-01  8:56                     ` Amit Shah
2009-10-01 10:48                       ` Amit Shah
2009-10-01 12:15                         ` Gerd Hoffmann
2009-10-07  9:25                           ` Amit Shah
2009-10-07  9:51                             ` Gerd Hoffmann
2009-10-07 10:06                               ` Amit Shah
2009-10-07 11:33                                 ` Gerd Hoffmann
2009-10-07 11:42                                   ` Amit Shah
2009-10-07 13:06                                     ` Gerd Hoffmann
2009-10-07 13:53                                       ` Amit Shah
2009-10-07 14:03                                         ` Gerd Hoffmann
2009-10-07 14:00                                       ` Anthony Liguori
2009-09-30 21:13   ` [Qemu-devel] [PATCH 1/6] char: Emit 'OPENED' events on char device open Anthony Liguori
2009-10-01  4:56     ` Amit Shah
2009-10-01  6:02       ` Amit Shah
2009-10-01 12:54       ` Anthony Liguori
2009-10-01 13:43         ` Gerd Hoffmann
2009-10-01 13:48           ` Anthony Liguori
2009-10-01 15:18             ` Gerd Hoffmann
2009-09-29 14:53 ` [Qemu-devel] virtio-console-bus, multiport, virtio-console-port 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=4AC3A5E6.6070703@redhat.com \
    --to=kraxel@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.