All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Paul Brook <paul@codesourcery.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG
Date: Tue, 20 Apr 2010 22:55:38 +0100	[thread overview]
Message-ID: <20100420215538.GO11723@shareable.org> (raw)
In-Reply-To: <4BCE1D3B.7000306@collabora.co.uk>

Ian Molton wrote:
> I've merely implemented one solution in qemu that other hypervisors
> *AND* the kernel already support, and that users want.

I think that's a good reason to include virtio-rng support in some form.

I suspect Paul's objection may have been due to an impression that
virtio-rng was a new thing developed by you, or an obscure thing that
nobody uses at the moment.

But: Does it have many users at present?

> virtio-serial
> -------------
>  * Impossible to interface with the kernels hwrng core and thus
>    useless for debugging it and related tools on the guest.

That was my question earlier: Impossible?  Seems like it should be
easy.  The kernel can bind its console to virtio-serial, so it should
be able to bind its hwrng to another one

> > If it's dumb enough to just trickle the entropy through, that would
> > seem a very good match to virtio-serial - apart from the guests which
> > already expect virtio-rng support.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Isn't that latter feature a good enough reason on its own? qemu supports
> a LOT of obscure hardware already - so "its weird" is also NOT a good
> reason against it. And its not even weird or unusual in this instance.

I agree, if there are more than a few obscure guests depending on it already.

However if it's only a handful and they can easily be upgraded to a
newer kernel using something else, maybe it's not worth it.

Your patches don't just add another device emulation.  They're a bit
more invasive than that.

> If qemu is only to support one way of doing any given operation then we
> should get rid of a LOT of other drivers - like most of the video
> drivers for example, and IDE/SCSI/SATA - well, all guests should just
> use virtio-block, right?

Sometimes, when I notice the increasing number of bug reports that
older guest OSes no longer work, I get the impression that's what KVM
developers would prefer :-)

For a certain class of users that's right.  Some users (generally the
"virtualization farm" variety) only need to run recent guests which
support virtio.

-- Jamie

  reply	other threads:[~2010-04-20 21:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 14:05 [Qemu-devel] [PATCH 0/2] VirtIO RNG Ian Molton
2010-03-30 14:12 ` [Qemu-devel] [PATCH 1/2] " Ian Molton
2010-03-30 14:13 ` [Qemu-devel] [PATCH 2/2] " Ian Molton
2010-04-01 12:17   ` Paul Brook
2010-04-01 12:30     ` Jamie Lokier
2010-04-01 14:03       ` Paul Brook
2010-04-02 10:13         ` Ian Molton
2010-04-03 15:06           ` Paul Brook
2010-04-13 14:41             ` Ian Molton
2010-04-13 15:01               ` Paul Brook
2010-04-13 15:32               ` Paul Brook
2010-04-20 15:15                 ` Ian Molton
2010-04-20 16:13                   ` Jamie Lokier
2010-04-20 19:52                     ` Ian Molton
2010-04-20 20:11                       ` Blue Swirl
2010-04-20 20:56                       ` Jamie Lokier
2010-04-20 21:31                         ` Ian Molton
2010-04-20 21:55                           ` Jamie Lokier [this message]
2010-04-21  7:43                           ` Gerd Hoffmann
2010-04-21  9:40                             ` Jamie Lokier
2010-04-21 12:34                               ` Ian Molton
2010-04-21 13:55                                 ` Gerd Hoffmann
2010-04-22 19:06                                   ` Ian Molton
2010-04-22 21:05                                     ` Jamie Lokier
2010-04-23 10:17                                       ` Ian Molton
2010-04-24  1:37                                         ` Jamie Lokier
2010-04-24  8:58                                           ` Ian Molton
2010-04-23  8:27                                     ` Gerd Hoffmann
2010-04-23  9:28                                       ` Ian Molton
2010-04-23 14:07                                         ` Gerd Hoffmann
2010-04-23 15:49                                           ` Ian Molton
2010-04-23 17:32                                             ` Jamie Lokier
2010-04-24  9:16                                               ` Ian Molton
2010-04-02 10:15       ` Ian Molton
2010-04-02 10:07     ` Ian Molton
2010-05-03 17:56   ` Anthony Liguori

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=20100420215538.GO11723@shareable.org \
    --to=jamie@shareable.org \
    --cc=ian.molton@collabora.co.uk \
    --cc=kraxel@redhat.com \
    --cc=paul@codesourcery.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.