[virtio-comment] Re: [virtio-dev] Re: [PATCH v6 3/4] admin: Add group member legacy register access commands

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jun 19, 2023 at 05:21:20PM +0000, Parav Pandit wrote:
> 
> 
> > From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> > Behalf Of Michael S. Tsirkin
> > Sent: Monday, June 19, 2023 1:11 PM
> 
> > > The "legacy interface of member device" is a vague term. As implementer,
> > reader I don't understand what that means.
> > > The commands clearly communicate the scope.
> > 
> > Add this as an example then.
> >
> I don't know what this means. 
> The section speaks for itself.
> We currently have,
> 
> Section 2.12.1 as "Group administration commands".
> Under this I added,
> 2.12.1.1 -> Legacy interface: legacy configuration access commands"
> 
> Above is no different than 
> "3.1.2 Legacy Interface: Device Initialization"
> 
> Tomorrow,
> 2.12.1.2 -> features config commands
> 2.12.1.3 -> 
>  
> > > > If you want to also have a type specific text, be my guest
> > > > "specifically, for an SRIOV type" ....
> > > >
> > > SRIOV in generic section doesn't make sense. It is covered in the pci transport
> > section.
> > 
> > When it's convenient to you you argue that it's clearer, when it's not you want it
> > generic.  Just mention it quickly and link to the specific text in the new section.
> >
> If you reviewer makes point "it is suggestion".
> If patch proposer makes a point its "argue" is not good way to discuss.
> So can you please avoid quoting "arguing".

To argue
	verb: give reasons or cite evidence in support of an idea,
	action, or theory, typically with the aim of persuading others to share
	one's view.

> 
> It is not my convenience.
> In the spec transport specific parts are not added.
> Hence, I said SR-IOV in generic to be avoided. It is better kept in the pci transport section.
> 
> > If you are intent on
> > spreading this all over the spec we'll need to rethink the whole approach.
> > 
> Where is this spread all over?
> In v5 it was self contained mainly in pci transport section.
> You asked to split to generic and pci.
> Fine, I split to two.

OK I see, I guess I wasn't clear. I was talking about as much as possible
using terms "owner" "member" "commands" "member_id" and so on,
such that the commands apply as generally as possible.
From that POV this needs a bit more work I think we can make more
things generic.

But I am looking for a way to keep this stuff as self contained
as possible. I don't much care whether the new tex is
under pci and admin command section just lists commands and links there,
or it is under admin and then pci section links there.

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/