content: Replace guest OS with driver
PATCH 1/1 content: Replace guest OS with driver
Currently device status field description and driver requirements section uses mix of terminology for the driver. These two sections sometimes call the driver as 'the guest OS' or 'the driver'.
Most of the cleanup around 'guest Os' was already done around commit 212c0cf3 in past. Clean up the remaining few references to just refer it as 'driver'.
This is an editorial change.
--- content.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
content.tex +5 -5
@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set): \begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before setting
@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper \begin{enumerate} \item Reset the device. -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device. -\item Set the DRIVER status bit: the guest OS knows how to drive the device. +\item Set the DRIVER status bit: the driver knows how to drive the device. \item\label{itm:General Initialization And Device Operation / Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits - understood by the OS and driver to the device. During this step the + understood by the driver to the device. During this step the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it. \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit. The driver MUST NOT accept
Signature · 18 lines
2.26.2 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: [email protected] Unsubscribe: [email protected] List help: [email protected] 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/
Quoted 5 lines · Parav Pandit
Currently device status field description and driver requirements section uses mix of terminology for the driver. These two sections sometimes call the driver as 'the guest OS' or 'the driver'.
Quoted 7 lines
Most of the cleanup around 'guest Os' was already done around commit
212c0cf3in past. Clean up the remaining few references to just refer it as 'driver'.This is an editorial change.
Signed-off-by Parav Pandit <[email protected]>
Do we plan to replace the "hypervisor" with "device" as well?
Thanks
Quoted 49 lines
--- content.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)content.tex +5
-6@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set): \begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before setting@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper \begin{enumerate} \item Reset the device. -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device. -\item Set the DRIVER status bit: the guest OS knows how to drive the device. +\item Set the DRIVER status bit: the driver knows how to drive the device. \item\label{itm:General Initialization And Device Operation / Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits - understood by the OS and driver to the device. During this step the + understood by the driver to the device. During this step the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it. \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit. The driver MUST NOT accept --2.26.2
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.
Quoted 9 lines
Subscribe: [email protected]
Unsubscribe: [email protected]
List help: [email protected]
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 9 lines · Parav Pandit
Currently device status field description and driver requirements section uses mix of terminology for the driver. These two sections sometimes call the driver as 'the guest OS' or 'the driver'.
Most of the cleanup around 'guest Os' was already done around commit
212c0cf3in past. Clean up the remaining few references to just refer it as 'driver'.This is an editorial change.
No, editorial changes are things like formatting, correcting cross references, resolving simple patch conflicts. We also have a minor cleanups rule including spelling and typos. I feel we've been through this discussion, no?
I'm insisting on clarifying this because you want to be an editor, and we could benefit from more editors, but given editors have commit access it's important to be clear what the role of an editor is, which is not to make decisions about content - it's a technical role.
Quoted 12 lines
Signed-off-by Parav Pandit <[email protected]>--- content.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)content.tex +0
-0@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set):
content.tex \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev · line 35
Quoted 10 lines
content.tex +2
-2\begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before setting
Actually, there is a subtle difference here that this is losing. "guest OS" really refers to e.g. Linux virtio core code here.
ACKNOWLEDGE and DRIVER are used by virtio core.
ACKNOWLEDGE tells you virtio core attached to device, and DRIVER tells you core found a device specific driver.
If you really want to make things better, let's find a way to explain all this.
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 478
Quoted 9 lines
content.tex +2
-2@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper \begin{enumerate} \item Reset the device. -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device. -\item Set the DRIVER status bit: the guest OS knows how to drive the device. +\item Set the DRIVER status bit: the driver knows how to drive the device.
besides the above, "drivers knows how to drive" sounds bad.
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 482
Quoted 4 lines
content.tex +1
-1\item\label{itm:General Initialization And Device Operation / Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits - understood by the OS and driver to the device. During this step the + understood by the driver to the device. During this step the
Again the "the OS" here referred to core virtio (e.g. ring features). Less of a problem to remove but if we come up with
a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it here, too.
Quoted 5 lines
content.tex +0
-0driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it. \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit. The driver MUST NOT acceptSignature · 1 line
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 25 lines · Michael S. Tsirkin
Quoted 7 lines · Parav Pandit
content.tex +0
-0@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set):content.tex \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev · line 35
Quoted 10 lines
content.tex +2
-2\begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before settingActually, there is a subtle difference here that this is losing. "guest OS" really refers to e.g. Linux virtio core code here.
ACKNOWLEDGE and DRIVER are used by virtio core.
Quoted 7 lines
ACKNOWLEDGE tells you virtio core attached to device, and DRIVER tells you core found a device specific driver.
If you really want to make things better, let's find a way to explain all this.
Agreed, this is a really old part of the spec, and likely had been written with the Linux device probing sequence in mind.
Basically, we want to distinguish between "something on the driver side has discovered the device" and "something on the driver side knows how to drive this specific device". If we consider "driver" as a catch-all of the whole thing talking to a device, we need to be extra descriptive (and we can add examples, as this is a non-normative section.)
For ACKNOWLEDGE, maybe "indicates that the driver has discovered the device and recognized it as a valid virtio device" (i.e. mostly what we have now), but also add "For example, this can indicate that non-device specific virtio driver code has attached to the device."
For DRIVER, maybe "indicates that the driver has discovered that it knows how to drive this device specifically. For example, this can indicate that device-specific driver code has attached to the device."
Probably need some more overhaul :) Not an editorial change in any case.
Quoted 17 lines
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 478
Quoted 9 lines
content.tex +2
-2@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper \begin{enumerate} \item Reset the device. -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device. -\item Set the DRIVER status bit: the guest OS knows how to drive the device. +\item Set the DRIVER status bit: the driver knows how to drive the device.besides the above, "drivers knows how to drive" sounds bad.
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 482
Quoted 4 lines
content.tex +1
-1\item\label{itm:General Initialization And Device Operation / Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits - understood by the OS and driver to the device. During this step the + understood by the driver to the device. During this step the
Quoted 4 lines
Again the "the OS" here referred to core virtio (e.g. ring features). Less of a problem to remove but if we come up with
a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it here, too.
Hm, I'm not sure how far we need to distinguish between generic and device-specific features in this case. The "driver" as the whole entity driving the device needs to decide on the subset; at this stage, it does not really matter which parts of the driver code accepted which feature. We probably want to be explicit that features are ring, transport, and device features, though.
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: [email protected]
Unsubscribe: [email protected]
List help: [email protected]
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/
Quoted 44 lines · Cornelia Huck
Quoted 25 lines · Michael S. Tsirkin
Quoted 7 lines · Parav Pandit
content.tex +0
-0@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set):content.tex \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev · line 35
Quoted 10 lines
content.tex +2
-2\begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before settingActually, there is a subtle difference here that this is losing. "guest OS" really refers to e.g. Linux virtio core code here.
ACKNOWLEDGE and DRIVER are used by virtio core.
Quoted 7 lines
ACKNOWLEDGE tells you virtio core attached to device, and DRIVER tells you core found a device specific driver.
If you really want to make things better, let's find a way to explain all this.
Agreed, this is a really old part of the spec, and likely had been written with the Linux device probing sequence in mind.
Basically, we want to distinguish between "something on the driver side has discovered the device" and "something on the driver side knows how to drive this specific device". If we consider "driver" as a catch-all of the whole thing talking to a device, we need to be extra descriptive (and we can add examples, as this is a non-normative section.)
Quoted 8 lines
For ACKNOWLEDGE, maybe "indicates that the driver has discovered the device and recognized it as a valid virtio device" (i.e. mostly what we have now), but also add "For example, this can indicate that non-device specific virtio driver code has attached to the device."
For DRIVER, maybe "indicates that the driver has discovered that it knows how to drive this device specifically. For example, this can indicate that device-specific driver code has attached to the device."
I feel examples are a weak way to document it - if we can not say what this is specifically, what purpose does it serve? Actually, we do have a distinction, between transport and device type. Can't we use that? It seems more consistent than "non-device specific" and "device specific".
SO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.
\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.
BTW somewhat related, I would maybe fix device-types/mem/description.tex:change
not to say "device driver", just "driver" for brevity.
Quoted 24 lines
Probably need some more overhaul :) Not an editorial change in any case.
Quoted 17 lines
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 478
Quoted 9 lines
content.tex +2
-2@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper \begin{enumerate} \item Reset the device. -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device. +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device. -\item Set the DRIVER status bit: the guest OS knows how to drive the device. +\item Set the DRIVER status bit: the driver knows how to drive the device.besides the above, "drivers knows how to drive" sounds bad.
content.tex \section{Device Initialization}\label{sec:General Initialization And Device Oper · line 482
Quoted 4 lines
content.tex +1
-1\item\label{itm:General Initialization And Device Operation / Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits - understood by the OS and driver to the device. During this step the + understood by the driver to the device. During this step theQuoted 4 lines
Again the "the OS" here referred to core virtio (e.g. ring features). Less of a problem to remove but if we come up with
a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it here, too.
Quoted 6 lines
Hm, I'm not sure how far we need to distinguish between generic and device-specific features in this case. The "driver" as the whole entity driving the device needs to decide on the subset; at this stage, it does not really matter which parts of the driver code accepted which feature. We probably want to be explicit that features are ring, transport, and device features, though.
OK.
Signature · 6 lines
MST --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Cornelia Huck
Quoted 25 lines · Michael S. Tsirkin
Quoted 7 lines · Parav Pandit
content.tex +0
-0@@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev following bits are defined (listed below in the order in which they would be typically set):content.tex \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev · line 35
Quoted 10 lines
content.tex +2
-2\begin{description} -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the device and recognized it as a valid virtio device. -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the +\item[DRIVER (2)] Indicates that the driver knows how to drive the device. \begin{note} There could be a significant (or infinite) delay before settingActually, there is a subtle difference here that this is losing. "guest OS" really refers to e.g. Linux virtio core code here.
ACKNOWLEDGE and DRIVER are used by virtio core.
Quoted 7 lines
ACKNOWLEDGE tells you virtio core attached to device, and DRIVER tells you core found a device specific driver.
If you really want to make things better, let's find a way to explain all this.
Agreed, this is a really old part of the spec, and likely had been written with the Linux device probing sequence in mind.
Basically, we want to distinguish between "something on the driver side has discovered the device" and "something on the driver side knows how to drive this specific device". If we consider "driver" as a catch-all of the whole thing talking to a device, we need to be extra descriptive (and we can add examples, as this is a non-normative section.)
For ACKNOWLEDGE, maybe "indicates that the driver has discovered the device and recognized it as a valid virtio device" (i.e. mostly what we have now), but also add "For example, this can indicate that non-device specific virtio driver code has attached to the device."
Quoted 7 lines
Quoted 3 lines
For DRIVER, maybe "indicates that the driver has discovered that it knows how to drive this device specifically. For example, this can indicate that device-specific driver code has attached to the device."
I feel examples are a weak way to document it - if we can not say what this is specifically, what purpose does it serve?
Not really documenting, but rather illustrating it.
Quoted 3 lines
Actually, we do have a distinction, between transport and device type. Can't we use that? It seems more consistent than "non-device specific" and "device specific".
What do we consider to be the "transport"? {pci,mmio,ccw} + virtio ring, or only {pci,mmio,ccw}? This might be confusiong, since at least in the Linux case, it is the virtio ring/generic code that sets ACKNOWLEDGE, while the pci/mmio/ccw code is not fiddling with the status at that stage.
Quoted 4 lines
SO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.
What is a "virtio device transport"?
Quoted 9 lines
\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.BTW somewhat related, I would maybe fix device-types/mem/description.tex:change
not to say "device driver", just "driver" for brevity.
That one makes sense to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 5 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 6:05 AM
Quoted 8 lines
SO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.
Above bisection is a implementation specific example of Linux (though valid and widely used one).
The UEFI virtio driver doesn't even have such two drivers.
In some OS variant drivers are merged to single kernel binary. Does driver only matter with device_driver structure or module binary?...
Driver is largely the software entity that drives the device.
I think we can keep the spec simple enough to not mix these details and just call it a "driver".
Quoted 5 lines
BTW somewhat related, I would maybe fix device-types/mem/description.tex:change
not to say "device driver", just "driver" for brevity.
Ok. will fix.
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: [email protected]
Unsubscribe: [email protected]
List help: [email protected]
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/
Quoted 10 lines · Parav Pandit
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 6:05 AMSO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.
Quoted 7 lines
Quoted 3 lines
\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.Above bisection is a implementation specific example of Linux (though valid and widely used one).
The UEFI virtio driver doesn't even have such two drivers. In some OS variant drivers are merged to single kernel binary.
which one?
Quoted 1 line
Does driver only matter with
device_driverstructure or module binary?...
Can't parse your question.
Quoted 2 lines
Driver is largely the software entity that drives the device.
I think we can keep the spec simple enough to not mix these details and just call it a "driver".
Not just linux there are lots of drivers like this. the two bits pass useful information the way you changed it this distinction is lots. I agree it is worth thinking what exactly does it mean. Since you researched it - what exactly do drivers
such as uefi and the unnamed "some OS variant" do exactly? when do they set ACKNOWLEDGE and when DRIVER?
Quoted 6 lines
Quoted 5 lines
BTW somewhat related, I would maybe fix device-types/mem/description.tex:change
not to say "device driver", just "driver" for brevity.Ok. will fix.
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: [email protected]
Unsubscribe: [email protected]
List help: [email protected]
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/
Quoted 18 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 4:48 PMQuoted 13 lines · Parav Pandit
Quoted 13 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 6:05 AMSO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.
Quoted 8 lines
Quoted 1 line
Above bisection is a implementation specific example of Linux (though valid
and widely used one).
Quoted 3 lines
The UEFI virtio driver doesn't even have such two drivers. In some OS variant drivers are merged to single kernel binary.
which one?
Flavor of a RHEL has inbuilt.
Quoted 6 lines
Quoted 1 line
Does driver only matter with
device_driverstructure or module binary?...Can't parse your question.
Quoted 2 lines
Driver is largely the software entity that drives the device.
I think we can keep the spec simple enough to not mix these details and just
Quoted 7 lines
call it a "driver".
Not just linux there are lots of drivers like this. the two bits pass useful information the way you changed it this distinction is lots.
I agree it is worth thinking what exactly does it mean.
Since you researched it - what exactly do drivers such as uefi and the unnamed "some OS variant" do exactly?
There is just one "driver" virtio_net_pci that has sets the required bits.
Quoted 2 lines
when do they set ACKNOWLEDGE and when DRIVER?
Not any different flow.
Entity is one.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 19 lines · Parav Pandit
Quoted 19 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 4:48 PMQuoted 14 lines · Parav Pandit
Quoted 5 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 6:05 AMQuoted 8 lines
SO I propose:
\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
device and recognized it as a valid virtio device transport.\item[DRIVER (2)] Indicates that a device type specific driver was found
and will attempt to attach to the device.Above bisection is a implementation specific example of Linux (though valid
Quoted 8 lines
Quoted 7 lines
and widely used one).
Quoted 3 lines
The UEFI virtio driver doesn't even have such two drivers. In some OS variant drivers are merged to single kernel binary.
which one?
Flavor of a RHEL has inbuilt.
What does this mean exactly? That virtio core is compiled into kernel? That does not matter at all.
Quoted 13 lines
Quoted 6 lines
Quoted 1 line
Does driver only matter with
device_driverstructure or module binary?...Can't parse your question.
Quoted 2 lines
Driver is largely the software entity that drives the device.
I think we can keep the spec simple enough to not mix these details and justQuoted 7 lines
call it a "driver".
Not just linux there are lots of drivers like this. the two bits pass useful information the way you changed it this distinction is lots.
I agree it is worth thinking what exactly does it mean.
Since you researched it - what exactly do drivers such as uefi and the unnamed "some OS variant" do exactly?
Quoted 6 lines
There is just one "driver"
virtio_net_pcithat has sets the required bits.Quoted 2 lines
when do they set ACKNOWLEDGE and when DRIVER?
Not any different flow.
Entity is one.
question is, what happens
- before ACKNOWLEDGE
- after ACKNOWLEDGE before DRIVER
?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 9 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 5:25 PMQuoted 1 line
Flavor of a RHEL has inbuilt.
What does this mean exactly? That virtio core is compiled into kernel? That does not matter at all.
Why does it does not matter? What is the definition of driver, is the device_structure structure or module binary?
Quoted 18 lines
Quoted 18 lines
Quoted 7 lines
Quoted 1 line
Does driver only matter with
device_driverstructure or module binary?...Can't parse your question.
Quoted 3 lines
Driver is largely the software entity that drives the device. I think we can keep the spec simple enough to not mix these details and just
Quoted 7 lines
call it a "driver".
Not just linux there are lots of drivers like this. the two bits pass useful information the way you changed it this distinction is lots. I agree it is worth thinking what exactly does it mean. Since you researched it - what exactly do drivers such as uefi and the unnamed "some OS variant" do exactly?
There is just one "driver"
virtio_net_pcithat has sets the required bits.Quoted 2 lines
when do they set ACKNOWLEDGE and when DRIVER?
Quoted 7 lines
Quoted 2 lines
Not any different flow.
Entity is one.question is, what happens
- before ACKNOWLEDGE
- after ACKNOWLEDGE before DRIVER
?
It follows the same sequence described in the spec as "driver" not as "guest OS".
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 10 lines · Parav Pandit
Quoted 9 lines
From: Michael S. Tsirkin <[email protected]>
Sent: Tuesday, May 16, 2023 5:25 PMQuoted 1 line
Flavor of a RHEL has inbuilt.
What does this mean exactly? That virtio core is compiled into kernel? That does not matter at all.
Why does it does not matter? What is the definition of driver, is the
device_structurestructure or module binary?
Neither. It's the part that handles transport or specific device.
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 7 lines
Quoted 1 line
Does driver only matter with
device_driverstructure or module binary?...Can't parse your question.
Quoted 3 lines
Driver is largely the software entity that drives the device. I think we can keep the spec simple enough to not mix these details and just
Quoted 7 lines
call it a "driver".
Not just linux there are lots of drivers like this. the two bits pass useful information the way you changed it this distinction is lots. I agree it is worth thinking what exactly does it mean. Since you researched it - what exactly do drivers such as uefi and the unnamed "some OS variant" do exactly?
There is just one "driver"
virtio_net_pcithat has sets the required bits.Quoted 2 lines
when do they set ACKNOWLEDGE and when DRIVER?
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Not any different flow.
Entity is one.question is, what happens
- before ACKNOWLEDGE
- after ACKNOWLEDGE before DRIVER
?It follows the same sequence described in the spec as "driver" not as "guest OS".
Looks like my description is spot on then - check vendor ID, set ACKNOWLEDGE, check device ID, see that it's a known good value matching device type we expect, set DRIVER.
Maybe replace with "transport part of the driver" and "device type specific part of the driver"? A bit verbose but if it rocks your boat ...
Signature · 18 lines
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: [email protected] Unsubscribe: [email protected] List help: [email protected] 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/