All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Ohad Ben-Cohen" <ohad@wizery.com>,
	"Sjur Brændeland" <sjur.brandeland@stericsson.com>
Cc: "Dmitry Tarnyagin" <dmitry.tarnyagin@stericsson.com>,
	"Sjur Brændeland" <sjur@brendeland.net>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Ido Yariv" <ido@wizery.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Erwan Yvin" <erwan.yvin@stericsson.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
Date: Thu, 21 Feb 2013 17:07:29 +1030	[thread overview]
Message-ID: <8738wqgok6.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAK=Wgbb0EeiCh504jsoX+izzi+ZogfEDttz2cHRd4pVXvQunQw@mail.gmail.com>

Ohad Ben-Cohen <ohad@wizery.com> writes:
> Hi Sjur,
>
> On Tue, Feb 12, 2013 at 1:49 PM,  <sjur.brandeland@stericsson.com> wrote:
>> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>
>> Add functions for creating, deleting and kicking host-side virtio rings.
>>
>> The host ring is not integrated with virtiqueues and cannot be managed
>> through virtio-config.
>
> Is that an inherent design/issue of vringh or just a description of
> the current vringh code ?

It's by design.  The producer (virtqueue) and consumer (vringh) are two
sides of the same coin, but they do different things.

virtqueue is a slightly higher level abstraction which assumes a
virtio_device, because every user so far has had one.  vringh doesn't,
because it's also aimed to underlie vhost.c which doesn't really have
one.

> This is possible of course thanks to the abstraction provided by
> virtio: remoteproc only implements a set of callbacks which virtio
> invokes when needed.
>
> Do we not want to follow a similar design scheme with vringh ?

Hmm... I clearly jumped the gun, assuming consensus was already reached.
I have put these patches *back* into pending-rebases, and they will not
be merged this merge window.

Cheers,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Ohad Ben-Cohen" <ohad@wizery.com>,
	"Sjur Brændeland" <sjur.brandeland@stericsson.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	"Sjur Brændeland" <sjur@brendeland.net>,
	netdev@vger.kernel.org,
	virtualization <virtualization@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dmitry Tarnyagin" <dmitry.tarnyagin@stericsson.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Erwan Yvin" <erwan.yvin@stericsson.com>,
	"Ido Yariv" <ido@wizery.com>
Subject: Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
Date: Thu, 21 Feb 2013 17:07:29 +1030	[thread overview]
Message-ID: <8738wqgok6.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAK=Wgbb0EeiCh504jsoX+izzi+ZogfEDttz2cHRd4pVXvQunQw@mail.gmail.com>

Ohad Ben-Cohen <ohad@wizery.com> writes:
> Hi Sjur,
>
> On Tue, Feb 12, 2013 at 1:49 PM,  <sjur.brandeland@stericsson.com> wrote:
>> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>
>> Add functions for creating, deleting and kicking host-side virtio rings.
>>
>> The host ring is not integrated with virtiqueues and cannot be managed
>> through virtio-config.
>
> Is that an inherent design/issue of vringh or just a description of
> the current vringh code ?

It's by design.  The producer (virtqueue) and consumer (vringh) are two
sides of the same coin, but they do different things.

virtqueue is a slightly higher level abstraction which assumes a
virtio_device, because every user so far has had one.  vringh doesn't,
because it's also aimed to underlie vhost.c which doesn't really have
one.

> This is possible of course thanks to the abstraction provided by
> virtio: remoteproc only implements a set of callbacks which virtio
> invokes when needed.
>
> Do we not want to follow a similar design scheme with vringh ?

Hmm... I clearly jumped the gun, assuming consensus was already reached.
I have put these patches *back* into pending-rebases, and they will not
be merged this merge window.

Cheers,
Rusty.

  parent reply	other threads:[~2013-02-21  6:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 11:49 [PATCHv2 vringh 0/3] Introduce CAIF Virtio driver sjur.brandeland
2013-02-12 11:49 ` sjur.brandeland
2013-02-12 11:49 ` [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings) sjur.brandeland
2013-02-12 11:49   ` sjur.brandeland
2013-02-20 16:05   ` Ohad Ben-Cohen
2013-02-20 16:05     ` Ohad Ben-Cohen
2013-02-20 23:01     ` Sjur Brændeland
2013-02-20 23:01       ` Sjur Brændeland
2013-02-21 13:47       ` Ohad Ben-Cohen
2013-02-21 13:47         ` Ohad Ben-Cohen
2013-02-21 17:28         ` Sjur Brændeland
2013-02-21 17:28           ` Sjur Brændeland
2013-02-21 17:55           ` Ohad Ben-Cohen
2013-02-21 17:55             ` Ohad Ben-Cohen
2013-02-21 19:36             ` Sjur Brændeland
2013-02-21 19:36               ` Sjur Brændeland
2013-02-23  9:49               ` Ohad Ben-Cohen
2013-02-23  9:49                 ` Ohad Ben-Cohen
2013-02-21  6:37     ` Rusty Russell [this message]
2013-02-21  6:37       ` Rusty Russell
2013-02-21 13:53       ` Ohad Ben-Cohen
2013-02-21 13:53         ` Ohad Ben-Cohen
2013-02-22  0:42         ` Rusty Russell
2013-02-22  0:42           ` Rusty Russell
2013-02-12 11:49 ` [PATCHv2 vringh 2/3] virtio: Add module driver macro for virtio drivers sjur.brandeland
2013-02-12 11:49 ` sjur.brandeland
2013-02-12 11:49 ` [PATCHv2 vringh 3/3] caif_virtio: Introduce caif over virtio sjur.brandeland
2013-02-12 11:49 ` sjur.brandeland
2013-02-18 23:37   ` Rusty Russell
2013-02-18 23:37   ` Rusty Russell

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=8738wqgok6.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=davem@davemloft.net \
    --cc=dmitry.tarnyagin@stericsson.com \
    --cc=erwan.yvin@stericsson.com \
    --cc=ido@wizery.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=sjur.brandeland@stericsson.com \
    --cc=sjur@brendeland.net \
    --cc=virtualization@lists.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 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.