Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [PATCH 1/3] transport-pci: Improve PCI legacy device layout description
Date: Mon, 27 Feb 2023 02:34:01 -0500	[thread overview]
Message-ID: <20230227023028-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB54817FED59372B4F965B473FDCAF9@PH0PR12MB5481.namprd12.prod.outlook.com>

On Mon, Feb 27, 2023 at 03:02:10AM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Saturday, February 25, 2023 6:09 PM
> > On Sun, Feb 26, 2023 at 12:29:59AM +0200, Parav Pandit wrote:
> > > Legacy interface PCI Device layout description has following issues.
> > >
> > > 1. repeated 'structure' word
> > > 2. virtio header was defined the 0.9.5 spec. In a legacy interface
> > >    section it is referred with different keywards
> > >    as (a) virtio header, (b) general headers, (c) legacy configuration
> > >    structure, (d) virtio common configuration structure and
> > >    (e) other fields.
> > > 3. Driver and device requirements listing is intermixed.
> > > 4. spelling error of structure
> > >
> > > Hence, rewrite the description to eliminate above issues as below.
> > >
> > > 1. Removed repeated structure word
> > > 2. Fix spelling of structure
> > > 3. Place all device requirements toegether 3. Define legacy
> > > configuration structure that consist of
> > >    a. legacy common configuration structure and
> > >    b. device specific configuration structure 4. Rewrite section
> > > around above changes
> > >
> > > This is only an editorial change.
> > 
> > No, editorial changes are things like spelling corrections.
> > 
> Got it. Will drop this remark.
> 
> > I have trouble reviewing
> > because I have no idea why you are making each change.
> > 
> After documenting legacy interface in the spec, we cannot claim that driver is the source = specification.

We document the *legacy interface*. What we don't is we don't document
legacy devices and drivers:

    Legacy devices and legacy drivers are not compliant with this
    specification.



> Currently transitional device and pci device do not scale well (or doesn't scale at all).
> We are working on supporting it and having better defined transitional device seems important part of it.
> 
> > E.g. you just rewrote a bunch of text and I frankly don't know why. For example:
> > 
> > 	-When using the legacy interface, transitional drivers
> > 	-MUST use the legacy configuration structure in BAR0 in the first
> > 	-I/O region of the PCI device, as documented below.
> > 
> > is now apparently:
> > 
> > 	+When used through the legacy interface, the legacy common
> > 	+configuration structure has the following layout:
> > 
> > and this is better? why? we are replacing a clear requirement which applied to
> 
> Because as I explained in the commit log, that one structure is named using 5 different names.

So maybe try just renaming. What you did is also convert a normative
statement to a non-normative one.


> > drivers with a vague statement which I can't say what it applies to.
> > 
> > Any chance of splitting these things up? Maybe that will help.
> > 
> That's a good idea. Yes. I will split these patches to smaller one.
> 
> > Apropos I don't know that we want to spend much time on legacy sections.
> Transitional devices are very much in use and documenting them well is important to build scalable transitional devices.
> 
> > Really with legacy code is the main source of documentation - if drivers work
> > then you are golden. If they don't appealing to spec will not help.
> 
> Yes, so don't want to add additional text. Just correcting the current one.


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-dev] Re: [PATCH 1/3] transport-pci: Improve PCI legacy device layout description
Date: Mon, 27 Feb 2023 02:34:01 -0500	[thread overview]
Message-ID: <20230227023028-mutt-send-email-mst@kernel.org> (raw)
Message-ID: <20230227073401.Z6ncfW_HgMneGoiJxDHRcUejIrkerllOi3L3-KAEdmU@z> (raw)
In-Reply-To: <PH0PR12MB54817FED59372B4F965B473FDCAF9@PH0PR12MB5481.namprd12.prod.outlook.com>

On Mon, Feb 27, 2023 at 03:02:10AM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Saturday, February 25, 2023 6:09 PM
> > On Sun, Feb 26, 2023 at 12:29:59AM +0200, Parav Pandit wrote:
> > > Legacy interface PCI Device layout description has following issues.
> > >
> > > 1. repeated 'structure' word
> > > 2. virtio header was defined the 0.9.5 spec. In a legacy interface
> > >    section it is referred with different keywards
> > >    as (a) virtio header, (b) general headers, (c) legacy configuration
> > >    structure, (d) virtio common configuration structure and
> > >    (e) other fields.
> > > 3. Driver and device requirements listing is intermixed.
> > > 4. spelling error of structure
> > >
> > > Hence, rewrite the description to eliminate above issues as below.
> > >
> > > 1. Removed repeated structure word
> > > 2. Fix spelling of structure
> > > 3. Place all device requirements toegether 3. Define legacy
> > > configuration structure that consist of
> > >    a. legacy common configuration structure and
> > >    b. device specific configuration structure 4. Rewrite section
> > > around above changes
> > >
> > > This is only an editorial change.
> > 
> > No, editorial changes are things like spelling corrections.
> > 
> Got it. Will drop this remark.
> 
> > I have trouble reviewing
> > because I have no idea why you are making each change.
> > 
> After documenting legacy interface in the spec, we cannot claim that driver is the source = specification.

We document the *legacy interface*. What we don't is we don't document
legacy devices and drivers:

    Legacy devices and legacy drivers are not compliant with this
    specification.



> Currently transitional device and pci device do not scale well (or doesn't scale at all).
> We are working on supporting it and having better defined transitional device seems important part of it.
> 
> > E.g. you just rewrote a bunch of text and I frankly don't know why. For example:
> > 
> > 	-When using the legacy interface, transitional drivers
> > 	-MUST use the legacy configuration structure in BAR0 in the first
> > 	-I/O region of the PCI device, as documented below.
> > 
> > is now apparently:
> > 
> > 	+When used through the legacy interface, the legacy common
> > 	+configuration structure has the following layout:
> > 
> > and this is better? why? we are replacing a clear requirement which applied to
> 
> Because as I explained in the commit log, that one structure is named using 5 different names.

So maybe try just renaming. What you did is also convert a normative
statement to a non-normative one.


> > drivers with a vague statement which I can't say what it applies to.
> > 
> > Any chance of splitting these things up? Maybe that will help.
> > 
> That's a good idea. Yes. I will split these patches to smaller one.
> 
> > Apropos I don't know that we want to spend much time on legacy sections.
> Transitional devices are very much in use and documenting them well is important to build scalable transitional devices.
> 
> > Really with legacy code is the main source of documentation - if drivers work
> > then you are golden. If they don't appealing to spec will not help.
> 
> Yes, so don't want to add additional text. Just correcting the current one.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2023-02-27  7:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-25 22:29 [PATCH 0/3] Cleanup for PCI transitional common cfg Parav Pandit
2023-02-25 22:29 ` [virtio-dev] " Parav Pandit
2023-02-25 22:29 ` [PATCH 1/3] transport-pci: Improve PCI legacy device layout description Parav Pandit
2023-02-25 22:29   ` [virtio-dev] " Parav Pandit
2023-02-25 23:08   ` Michael S. Tsirkin
2023-02-25 23:08     ` [virtio-dev] " Michael S. Tsirkin
2023-02-27  3:02     ` Parav Pandit
2023-02-27  3:02       ` [virtio-dev] " Parav Pandit
2023-02-27  7:34       ` Michael S. Tsirkin [this message]
2023-02-27  7:34         ` [virtio-dev] " Michael S. Tsirkin
2023-02-25 22:30 ` [PATCH 2/3] transport-pci: Split notes of PCI Device Layout Parav Pandit
2023-02-25 22:30   ` [virtio-dev] " Parav Pandit
2023-02-25 23:15   ` Michael S. Tsirkin
2023-02-25 23:15     ` [virtio-dev] " Michael S. Tsirkin
2023-02-27  3:05     ` Parav Pandit
2023-02-27  3:05       ` [virtio-dev] " Parav Pandit
2023-02-27  7:35       ` [virtio-dev] " Michael S. Tsirkin
2023-02-25 22:30 ` [PATCH 3/3] transport-pci: Relocate common config legacy interface Parav Pandit
2023-02-25 22:30   ` [virtio-dev] " Parav Pandit
2023-02-25 23:16   ` Michael S. Tsirkin
2023-02-25 23:16     ` [virtio-dev] " Michael S. Tsirkin
2023-02-27  3:07     ` Parav Pandit
2023-02-27  3:07       ` [virtio-dev] " Parav Pandit
2023-02-25 23:17 ` [PATCH 0/3] Cleanup for PCI transitional common cfg Michael S. Tsirkin
2023-02-25 23:17   ` [virtio-dev] " Michael S. Tsirkin
2023-02-27  8:59   ` 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=20230227023028-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