[PATCH v2 00/17] admin: reconfirming the TC charter

On Tue, 9 Feb 2021 05:02:10 -0500 "Michael S. Tsirkin" <> wrote:
> On Mon, Feb 08, 2021 at 05:15:55PM +0100, Halil Pasic wrote: >
> On Mon, 8 Feb 2021 07:15:57 -0500 > > "Michael S. Tsirkin" <> wrote: > >
> >
> we are adding new device types all the time. > >
> no point in trying to list them all in the charter. > > >  > >
> Signed-off-by: Michael S. Tsirkin <> > >
> Reviewed-by: Cornelia Huck <> > > > --- > >
>  charter.html
17 +

----------------

> >
>  1 file changed, 1 insertion(+), 16 deletions(-) > > >  > >
> diff --git a/charter.html b/charter.html > >
> index 38cad98..82fb981 100644 > > > --- a/charter.html > > > +++ b/charter.html > > > @@ -80,22 +80,7 @@ > >
>
Specification of device-specific configuration. > > >
<ol class="vanilla-lower-alpha"> > > >
<li> > > > -
For network devices. > > > -
</li> > > > -
<li> > > > -
For block storage devices. > > > -
</li> > > > -
<li> > > > -
For entropy devices. > > > -
</li> > > > -
<li> > > > -
For console devices. > > > -
</li> > > > -
<li> > > > -
For memory ballooning devices. > > > -
</li> > > > -
<li> > > > -
For SCSI endpoint devices. > > > +
Normative requirements for specified device types. > > >
</li>
> >  >
> Does it make sense to keep the list with only a single element? > >
> > >
<li> > >
>
Non-normative advice for designing new device types.
> >  >
> I believe the the rest of the items starting with the one immediately >
> above should be moved up one level higher. These don't seem to be sub >
> deliverables of 'device-specific configuration' but top level >
> deliverables...
>
> Well if you look at the spec they are all under section
> 5 Device Types. The only exception is
> Appendix B. Creating New Device Types.
> I will move that one out.
>  What confuses my is the configuration word in the phrase 'device-specific configuration'. I assumed that is about the config space, but it seems your intention for deliverable 2 is to cover everything that is device type specific (config space layout, virtqueues and their purpose, the communication protocol between driver and device (message formats, etc)).
I had something like this in mind (please compare to the attachment):  4 Deliverables
1 Specification of feature negotiation, configuration and queues, from both driver and device points of view.
1 Specifically for virtio over PCI.
2 Specifically for virtio over mmio.
3 Specifically for virtio over channel I/O.
4 Specifically for other transports as decided by TC.
2 Normative requirements for specified device types.
3 Non-normative advice for designing new device types.
4 List of reserved device numbers for non-specified device types. (This section is likely to see ongoing maintenance).
5 List of reserved feature numbers for non-specified features for each device type. (This section is likely to see ongoing maintenance).
6 Non-normative code examples for operation of driver/device side of buffers.
7 Non-normative guide for creating devices and drivers which also support a legacy mode.
>
Attachment:
Screen Shot 2021-02-09 at 12.26.32.png
Description:  PNG image