From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [PATCH v3 1/2] virtio-net: Describe dev cfg fields read only
Date: Tue, 21 Feb 2023 13:08:12 -0500 [thread overview]
Message-ID: <20230221130713-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB54815BA778BE4039755B7D6FDCA59@PH0PR12MB5481.namprd12.prod.outlook.com>
On Tue, Feb 21, 2023 at 05:59:52PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, February 21, 2023 12:52 PM
> >
> > On Tue, Feb 21, 2023 at 05:50:09PM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Tuesday, February 21, 2023 12:42 PM
> > > > >
> > > > > What does "bits (for the driver)" mean? It made sense together
> > > > > with "read-only", but I would drop "(for the driver)" as well.
> > > >
> > > > Ouch Parav are you making search and replace changes without reading
> > > > the result? Pls don't.
> > > >
> > > It was wrong to keep the "for the driver".
> > > I will fix this.
> > >
> > > >
> > > > > > VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE.
> > > > > >
> > > > > > \begin{lstlisting}
> > > > > > @@ -167,14 +167,14 @@ \subsection{Device configuration
> > > > layout}\label{sec:Device Types / Network Device
> > > > > > #define VIRTIO_NET_S_ANNOUNCE 2
> > > > > > \end{lstlisting}
> > > > > >
> > > > > > -The following driver-read-only field,
> > > > > > \field{max_virtqueue_pairs} only exists if
> > > > > > +The following field, \field{max_virtqueue_pairs} only exists if
> > > > > > VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is set. This field
> > > > > > specifies the maximum number of each of transmit and receive
> > > > > > virtqueues (receiveq1\ldots receiveqN and transmitq1\ldots
> > > > > > transmitqN
> > > > > > respectively) that can be configured once at least one of these
> > > > > > features is
> > > > negotiated.
> > > > > >
> > > > > > -The following driver-read-only field, \field{mtu} only exists
> > > > > > if -VIRTIO_NET_F_MTU is set. This field specifies the maximum
> > > > > > MTU for the driver to
> > > > > > +The following field, \field{mtu} only exists if
> > > > > > +VIRTIO_NET_F_MTU is set. This field specifies the maximum MTU
> > > > > > +for the driver to
> > > > > > use.
> > > > > >
> > > > > > The following two fields, \field{speed} and \field{duplex},
> > > > > > only @@
> > > > > > -261,6 +261,8 @@ \subsection{Device configuration
> > > > > > layout}\label{sec:Device Types / Network Device
> > > > > >
> > > > > > \drivernormative{\subsubsection}{Device configuration
> > > > > > layout}{Device Types / Network Device / Device configuration
> > > > > > layout}
> > > > > >
> > > > > > +All the device configuration fields are read-only for the driver.
> > > > >
> > > > > Not sure if this makes a good normative clause, I would rather
> > > > > give the driver something actionable:
> > > > >
> > > > > "A driver SHOULD NOT try to write to any of the device
> > > > > configuration fields."
> > > >
> > > > Agree it's not a normative statement as is.
> > > > MUST NOT actually - they were always read only.
> > > > And no need to "try" just don't write period.
> > > >
> > > Saying driver must not write it, doesn't make it read only for the device.
> >
> > no but this is not what your patch said either. It's read only for the driver.
> >
> It is read-only for the driver because the device doesn't treat them as writable.
> Do you mean it should be better written as,
>
> These fields are read-only for the driver, hence any writes by the driver to it will be ignored by the device.
>
> ?
I just concur with Cornelia.
> > > Hence, it should be mentioned as read-only fields, so when the driver writes
> > something to read-only fields, it can be considered as undefined behavior on
> > such fields.
> > >
> >
> > In the description not in the normative statements. normative sections just tell
> > driver what it must and must not do, in the standard RFC terms.
> >
> Got it.
> I will shift them as read-only in the description section.
> And normative in the device and driver section.
> Device section:
> Any writes to config space fields is ignored by the device, because these are read-only fields for the driver.
writes is plural so "are ignored"
but more importantly use rfc terms in normative sections.
>
> Driver section:
> Driver must not write to read-only fields.
next prev parent reply other threads:[~2023-02-21 18:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 15:45 [virtio-comment] [PATCH v3 0/2] virtio-net: Improve dev config layout Parav Pandit
2023-02-17 15:45 ` [PATCH v3 1/2] virtio-net: Describe dev cfg fields read only Parav Pandit
2023-02-20 14:46 ` [virtio-dev] " David Edmondson
2023-02-21 15:37 ` [virtio-dev] " Cornelia Huck
2023-02-21 17:42 ` Michael S. Tsirkin
2023-02-21 17:50 ` Parav Pandit
2023-02-21 17:52 ` Michael S. Tsirkin
2023-02-21 17:59 ` Parav Pandit
2023-02-21 18:08 ` Michael S. Tsirkin [this message]
2023-02-22 9:01 ` [virtio-dev] " Cornelia Huck
2023-02-22 11:50 ` Michael S. Tsirkin
2023-02-22 12:07 ` [virtio-comment] " Cornelia Huck
2023-02-22 12:55 ` Michael S. Tsirkin
2023-02-22 13:26 ` [virtio-comment] " Cornelia Huck
2023-02-23 5:50 ` Parav Pandit
2023-02-17 15:45 ` [PATCH v3 2/2] virtio-net: Define cfg fields before description Parav Pandit
2023-02-20 14:42 ` [virtio-comment] " David Edmondson
2023-02-21 13:30 ` [PATCH v3 0/2] virtio-net: Improve dev config layout Parav Pandit
[not found] ` <875ybej6hb.fsf@redhat.com>
2023-03-07 17:25 ` [virtio-dev] " Parav Pandit
2023-03-08 10:07 ` [virtio-dev] Re: [virtio-comment] " Cornelia Huck
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=20230221130713-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox