All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: Alon Levy <alevy@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
	Avi Kivity <avi@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
Date: Wed, 03 Nov 2010 13:17:31 -0500	[thread overview]
Message-ID: <4CD1A73B.2010406@codemonkey.ws> (raw)
In-Reply-To: <4CD1A406.3090909@collabora.co.uk>

On 11/03/2010 01:03 PM, Ian Molton wrote:
>
> The virtio driver enfoces the PID field and understands the packet 
> format used. Its better than using serial. Its also just one driver - 
> which doesnt have any special interdependencies and can be extended or 
> got rid of in future if and when better things come along.

Why is it better than using virtio-serial?

>
>> In the very, very short term, I think an external backend to QEMU also
>> makes a lot of sense because that's something that Just Works today.
>
> Whos written that? The 2007 patch I've been working on and updating 
> simply fails to work altogether without huge alterations on current qemu.
>
> My current patch touches a tiny part of the qemu sources. It works today.

But it's not at all mergable in the current form.  If you want to do the 
work of getting it into a mergable state (cleaning up the coding style, 
moving it to hw/, etc.) than I'm willing to consider it.  But I don't 
think a custom virtio transport is the right thing to do here.

However, if you want something that Just Works with the least amount of 
code possible, just split it into a separate process and we can stick it 
in a contrib/ directory or something.

>
>> I
>> think we can consider integrating it into QEMU (or at least simplifying
>> the execution of the backend) but integrating into QEMU is going to
>> require an awful lot of the existing code to be rewritten. Keeping it
>> separate has the advantage of allowing something to Just Work as an
>> interim solution as we wait for proper support in Spice.
>
> I dont know why you think integrating it into qemu is hard? I've 
> already done it. 

Adding a file that happens to compile as part of qemu even though it 
doesn't actually integrate with qemu in any meaningful way is not 
integrating.  That's just build system manipulation.

Regards,

Anthony Liguori

> I added one virtio driver and a seperate offscreen renderer. it 
> touches the qemu code in *one* place. There should be no need to 
> rewrite anything.


WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	QEMU Developers <qemu-devel@nongnu.org>,
	virtualization@lists.linux-foundation.org,
	virtualization@lists.osdl.org, Alon Levy <alevy@redhat.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
Date: Wed, 03 Nov 2010 13:17:31 -0500	[thread overview]
Message-ID: <4CD1A73B.2010406@codemonkey.ws> (raw)
In-Reply-To: <4CD1A406.3090909@collabora.co.uk>

On 11/03/2010 01:03 PM, Ian Molton wrote:
>
> The virtio driver enfoces the PID field and understands the packet 
> format used. Its better than using serial. Its also just one driver - 
> which doesnt have any special interdependencies and can be extended or 
> got rid of in future if and when better things come along.

Why is it better than using virtio-serial?

>
>> In the very, very short term, I think an external backend to QEMU also
>> makes a lot of sense because that's something that Just Works today.
>
> Whos written that? The 2007 patch I've been working on and updating 
> simply fails to work altogether without huge alterations on current qemu.
>
> My current patch touches a tiny part of the qemu sources. It works today.

But it's not at all mergable in the current form.  If you want to do the 
work of getting it into a mergable state (cleaning up the coding style, 
moving it to hw/, etc.) than I'm willing to consider it.  But I don't 
think a custom virtio transport is the right thing to do here.

However, if you want something that Just Works with the least amount of 
code possible, just split it into a separate process and we can stick it 
in a contrib/ directory or something.

>
>> I
>> think we can consider integrating it into QEMU (or at least simplifying
>> the execution of the backend) but integrating into QEMU is going to
>> require an awful lot of the existing code to be rewritten. Keeping it
>> separate has the advantage of allowing something to Just Work as an
>> interim solution as we wait for proper support in Spice.
>
> I dont know why you think integrating it into qemu is hard? I've 
> already done it. 

Adding a file that happens to compile as part of qemu even though it 
doesn't actually integrate with qemu in any meaningful way is not 
integrating.  That's just build system manipulation.

Regards,

Anthony Liguori

> I added one virtio driver and a seperate offscreen renderer. it 
> touches the qemu code in *one* place. There should be no need to 
> rewrite anything.

  reply	other threads:[~2010-11-03 18:17 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 15:59 [PATCH] Implement a virtio GPU transport Ian Molton
2010-10-10 15:11 ` Avi Kivity
2010-10-19 10:31   ` Ian Molton
2010-10-19 10:31     ` [Qemu-devel] " Ian Molton
2010-10-19 10:39     ` Avi Kivity
2010-10-19 10:39       ` [Qemu-devel] " Avi Kivity
2010-10-27 13:00       ` Ian Molton
2010-10-27 13:00         ` Ian Molton
2010-10-28  9:27         ` Avi Kivity
2010-10-28  9:27           ` Avi Kivity
2010-10-28 11:54           ` Ian Molton
2010-10-28 11:54             ` Ian Molton
2010-10-28 14:24             ` Avi Kivity
2010-10-28 14:24               ` Avi Kivity
2010-10-28 14:43               ` Anthony Liguori
2010-10-28 14:43                 ` Anthony Liguori
2010-10-28 19:50                 ` Ian Molton
2010-10-28 19:50                   ` Ian Molton
2010-10-28 20:14                   ` Anthony Liguori
2010-10-28 20:14                     ` Anthony Liguori
2010-10-28 21:41                     ` Ian Molton
2010-10-28 21:41                       ` Ian Molton
2010-10-28 19:52               ` Ian Molton
2010-11-01 10:42                 ` Avi Kivity
2010-11-01 13:21                   ` Anthony Liguori
2010-11-01 13:21                     ` Anthony Liguori
2010-11-01 15:49                     ` Ian Molton
2010-11-01 15:49                       ` Ian Molton
2010-11-01 15:57                       ` Anthony Liguori
2010-11-01 15:57                         ` Anthony Liguori
2010-11-03 17:49                         ` Ian Molton
2010-11-03 17:49                           ` Ian Molton
2010-11-01 15:50                   ` Ian Molton
2010-10-29 11:18         ` Rusty Russell
2010-10-29 11:18           ` Rusty Russell
2010-10-29 11:49           ` Ed Tomlinson
2010-10-29 11:49             ` Ed Tomlinson
2010-10-29 11:49             ` Ed Tomlinson
2010-10-29 13:05           ` Anthony Liguori
2010-10-29 13:05             ` Anthony Liguori
2010-11-01 11:53             ` Alon Levy
2010-11-01 11:53               ` Alon Levy
2010-11-01 13:28               ` Anthony Liguori
2010-11-01 13:28                 ` Anthony Liguori
2010-11-03 18:03                 ` Ian Molton
2010-11-03 18:03                   ` Ian Molton
2010-11-03 18:17                   ` Anthony Liguori [this message]
2010-11-03 18:17                     ` Anthony Liguori
2010-11-05 18:05                     ` Ian Molton
2010-11-05 18:05                       ` Ian Molton
2010-11-10 17:22                       ` Ian Molton
2010-11-10 17:22                         ` Ian Molton
2010-11-10 17:47                         ` Anthony Liguori
2010-11-10 17:47                           ` Anthony Liguori
2010-11-12 12:14                           ` Ian Molton
2010-11-12 12:14                             ` Ian Molton
2010-11-12 13:21                             ` Anthony Liguori
2010-11-12 13:21                               ` Anthony Liguori
2010-11-04  9:13                   ` Alon Levy
2010-11-04  9:13                     ` Alon Levy
2010-11-05 17:57                     ` Ian Molton
2010-11-05 17:57                       ` Ian Molton
2010-11-03 17:50           ` Ian Molton
2010-11-03 17:50             ` Ian Molton

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=4CD1A73B.2010406@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=alevy@redhat.com \
    --cc=avi@redhat.com \
    --cc=ian.molton@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=virtualization@lists.osdl.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.