From ba7a7e40985c4fbdcf77722550611d32180c908b Mon Sep 17 00:00:00 2001 From: Bill Mills Date: Wed, 28 Jan 2026 08:34:08 -0500 Subject: [PATCH] virtio-msg: eliminate non-ASCII characters The transport-msg.tex file uses some UTF-8 characters while the rest of the spec does not. Change these to ASCII characters. * Change paired/smart double quotes with ASCII double quotes * Change em-dash used on number ranges to ASCII dash * Change em-dash used to denote a parenthetical statement to use commas Signed-off-by: Bill Mills --- transport-msg.tex | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/transport-msg.tex b/transport-msg.tex index d4e31d7..0232ab1 100644 --- a/transport-msg.tex +++ b/transport-msg.tex @@ -281,8 +281,8 @@ \subsubsection{Device Numbers and Enumeration} might inform the bus of available device numbers and their properties. \end{itemize} -Once a bus confirms that a device number is valid—regardless of the discovery -method—it normally issues \msgref{GET_DEVICE_INFO} to retrieve the device and +Once a bus confirms that a device number is valid, regardless of the discovery +method, it normally issues \msgref{GET_DEVICE_INFO} to retrieve the device and vendor IDs before registering the device with the host OS so the usual Virtio driver binding process can begin. @@ -292,8 +292,8 @@ \subsubsection{Device Numbers and Enumeration} device on a given bus instance and MUST NOT forward transport messages for a device number that has not been validated. \item A bus implementation SHOULD provide the driver with sufficient - information—either via \busref{GET_DEVICES} or equivalent platform - data—to discover each valid device number. + information, either via \busref{GET_DEVICES} or equivalent platform + data, to discover each valid device number. \end{itemize} \subsubsection{Configuration Generation Count} @@ -786,7 +786,7 @@ \subsubsection{Driver Notifications} virtqueue. \item Each \msgref{EVENT_AVAIL} MUST identify the target virtqueue index. \item If VIRTIO\_F\_NOTIFICATION\_DATA has been negotiated, the driver MUST - populate the “next offset and wrap” fields so the device can locate the + populate the "next offset and wrap" fields so the device can locate the head of the updated ring; otherwise those fields MUST be zero. \end{itemize} @@ -1533,7 +1533,7 @@ \subsubsection{Overview} \busdef{GET_DEVICES} The driver-side bus uses this request to enumerate device numbers on the -device-side bus. The response describes a “window” of device numbers and signals +device-side bus. The response describes a "window" of device numbers and signals which entries are present. \begin{lstlisting} @@ -1559,7 +1559,7 @@ \subsubsection{Overview} Example: a request with \textbf{offset}=0, \textbf{count}=16 might produce \textbf{bitmap}=0b00100101 00000000 and \textbf{next_offset}=16. That indicates -devices 0, 2, and 5 are present within the 0–15 window and suggests continuing +devices 0, 2, and 5 are present within the 0-15 window and suggests continuing at device number 16. \paragraph{Intended usage} @@ -1626,8 +1626,8 @@ \subsubsection{Overview} \hline DEVICE\_BUS\_STATE\_READY & 0x0001 & Device is present and ready. \\ DEVICE\_BUS\_STATE\_REMOVED & 0x0002 & Device is no longer present. \\ -Reserved & 0x0003–0x7FFF & Reserved for standard use. \\ -Implementation-defined & 0x8000–0xFFFF & MAY be used by the bus implementation. \\ +Reserved & 0x0003-0x7FFF & Reserved for standard use. \\ +Implementation-defined & 0x8000-0xFFFF & MAY be used by the bus implementation. \\ \hline \end{tabular}