Re: [PATCH v3 3/3] virtio: introduce SUSPEND and RESUME feature

On 6/26/2025 11:42 PM, Cornelia Huck wrote:

> On Thu, Jun 26 2025, "Zhu, Lingshan"<[email protected]> wrote:
>
>> On 6/26/2025 7:59 PM, Parav Pandit wrote:
>>
>>>> From: Zhu Lingshan<[email protected]>
>>>> Sent: 23 June 2025 02:07 PM
>>>> @@ -629,6 +632,54 @@ \section{Device Cleanup}\label{sec:General
>>>> Initialization And Device Operation /
>>>>
>>>>    Thus a driver MUST ensure a virtqueue isn't live (by device reset) before
>>>> removing exposed buffers.
>>>>
>>>> +\section{Device Suspend}\label{sec:General Initialization And Device
>>>> +Operation / Device Suspend}
>>>> +
>>>> +If VIRTIO_F_SUSPEND is negotiated, the driver is eligible to suspend the
>>>> device by setting the SUSPEND bit in \field{device status} to 1, and the device
>>>> SHOULD set the DRIVER_OK bit to 0 once it has been suspended.
>>>> +
>>> You ignored the inputs.
>>> I do not agree to add the "SHOULD" normative wording in the general description area.
>>> The reasoning is explained already.
>>> Please adapt to the existing style of this spec to keep the normative in requirements section.
>>>
>>> If VIRTIO_F_SUSPEND is negotiated, the driver is eligible to suspend the
>>> device by setting the SUSPEND bit in \field{device status} to 1, and the device
>>> sets the DRIVER_OK bit to 0 once it has been suspended.
>>>
>>> Is this really that hard to write above way?
>> I believe you totally ignored my replies in the last thread.
>> There are no rules forbid using "SHOULD" in any non-normative sections.
>> Now here I copy the reply here again:
>>
>> In the spec section 1.3 Terminology, it says:
>>
>> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.
>>
>> RFC 2119 says:
>>
>> SHOULD This word, or the adjective "RECOMMENDED", mean that there
>>      may exist valid reasons in particular circumstances to ignore a
>>      particular item, but the full implications must be understood and
>>      carefully weighed before choosing a different course.
>>
>>
>> Here this "SHOULD" exactly conforms to the definition.
>>
>> "SHOULD" has already been used in non-normative sections, for example:
>> 2.5.4 Legacy Interfaces: when using the legacy interface, drivers SHOULD read these fields multiple times until two reads generate a consistent result.
>>
>> The spec does not say: “SHOULD” can only be used in driver or device requirements section.
>>
>> @MST, we need your input
>>
> Not MST, but you can have my input.
>
> We refer to the RFC for the definitions of SHOULD and friends, it does
> not say where to use them.

exactly

>
> The intention is to use them in normative statements only, so that
> implementers have clear guidelines on the requirements. The legacy
> sections are arguably a special case (for implementers who want to
> support legacy implementations.) I don't think we want the all-caps key
> words leaking into other sections (any more than what might have
> happened already.)

so this is a new requirement, we need to document these guidance

>