All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	virtio@lists.oasis-open.org, virtio-comment@lists.oasis-open.org
Cc: Halil Pasic <pasic@linux.ibm.com>
Subject: [virtio] Re: [PATCH 1/1] split-ring: clarify the field len in the used ring
Date: Mon, 29 Nov 2021 17:32:59 +0100	[thread overview]
Message-ID: <87bl22j51g.fsf@redhat.com> (raw)
In-Reply-To: <20211126171233.16083-1-pasic@linux.ibm.com>

On Fri, Nov 26 2021, Halil Pasic <pasic@linux.ibm.com> wrote:

> The current descriptor is misleading: "the descriptor chain which was
> used" generally includes both the descriptors that map the device read
> only, and descriptors that  map the device write only portions of the
> buffer described by the descriptor chain. The argument that "used" means
> "written to" does not stand because one has to "use" the descriptor
> chain even when the whole buffer is device read only.
>
> One can argue, that the most straightforward way to interpret the phrase
> "total length of that descriptor chain" (without context) like the
> length of the  list is usually defined: i.e. like the number of
> descriptors that constitute the chain. This is clearly not what we want
> here. Another intuitive way to interpret "total length of that
> descriptor chain" is size of the buffer mapped by the descriptor chain.
> This is not what we want either. In fact such wrongful interpretations
> have caused bugs in the wild.
>
> On the other hand, the text below the listing that gets modified here
> clearly describes the semantics of \field{len}. So let us replace
> the ambiguous explanation in the listing, with a hopefully non-ambiguous
> one.
>
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
>  split-ring.tex | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Thanks, pushed as an editorial update.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


      parent reply	other threads:[~2021-11-29 16:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 17:12 [PATCH 1/1] split-ring: clarify the field len in the used ring Halil Pasic
2021-11-29 10:16 ` [virtio-comment] " Stefan Hajnoczi
2021-11-29 12:23   ` [virtio] " Cornelia Huck
2021-11-29 13:04     ` Halil Pasic
2021-11-29 16:32 ` Cornelia Huck [this message]

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=87bl22j51g.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio@lists.oasis-open.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.