[PATCH v5 3/7] drm/sched: Move schedule policy to scheduler

[Luben Tuikov]

One more very important thing!

Once you add an R-V tag, you cannot change the patch and keep the R-V, when reposting it.

If you change the code and thus the patch changes, you _*must*_ remove the R-V tag,
to let people know that there's changes which need reviewing.

Regards,
Luben

On 2023-10-12 01:54, Luben Tuikov wrote:
> On 2023-10-12 00:31, Matthew Brost wrote:
>> On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote:
>>> On 2023-10-11 19:58, Matthew Brost wrote:
>>>> Rather than a global modparam for scheduling policy, move the scheduling
>>>> policy to scheduler so user can control each scheduler policy.
>>>>
>>>> v2:
>>>>   - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
>>>>   - Only include policy in scheduler (Luben)
>>>> v3:
>>>>   - use a ternary operator as opposed to an if-control (Luben)
>>>>   - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
>>>>   - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
>>>>   - Update commit message (Boris)
>>>>   - Fix v3d build (CI)
>>>>   - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
>>>>   - Don't update modparam doc (Luben)
>>>> v4:
>>>>   - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)
>>>>
>>>> Reviewed-by: Luben Tuikov <luben.tuikov at amd.com>
>>>> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
>>>
>>> Was the R-V added by hand? (As in editing the commit message manually?)
>>>
>>
>> Yes.
>>
>>> I use automated tools for this which do not re-order the tags.
>>> IOW, the S-O-B is first as this is how it appears in the patch,
>>> then the R-V most probably added by automated tools, and then
>>> any other as are tacked on by other automated tools.
>>>
>>
>> Ok, so always add tags in order starting with S-O-B?
> 
> Yes!
> 
> The S-O-B tag you add when you write the commit and then you post
> it up to a mailing list, it's mandatory and it's always there.
> It's most likely the first, top tag.
> 
> Then various other scripts and tools start adding tags in an automated way,
> and those tags are just appended below any existing tags.
> 
> Generally, always follow a natural order (meaning least amount of energy
> expenditure--if you have to edit to reorder, that is extra energy expenditure
> and nature doesn't like that). Make it like a letter you'd get from or write to
> your bank, attorney, etc.
> 	These are tags you add when you craft your commit:
> Cc: goes first, followed by other tags whose values
> Cc: are personal emails, i.e. people. These are people
> Cc: you want to let know of this commit. This is followed
> Cc: by other personal tags, for instance,
> Co-developed-by: or
> Suggested-by: Another personal tag is,
> Reported-by: which must be followed by a Link tag with
> Link: the link of the report. This could also be a link to anything else. You can also add a
> Fixes: tag which should follow a --pretty %h (\"%s\") format.
> Closes: link to the bug the patch closes
> Signed-off-by: You
> 	Then scripts and tools (or even people) would append the tag list with:
> Tested-by: someone reliable, could have more than one instance of this tag,
> Acked-by: someone
> Reviewed-by: someone
> 
> There are no empty lines between tags. They form a block paragraph as they would
> if/when added by a script. (I never add _any_ tag manually.)
> 
> So, for instance, you may have:
> 
> Cc: Luben
> Signed-off-by: Matt
> 
> And when the patch is R-V-ed this becomes (least amount of energy, append at the bottom),
> 
> Cc: Luben
> Signed-off-by: Matt
> Reviewed-by: Luben
> 
> Then other tags may be appended, depending on the path the patch takes to land in a tree.
> 
> Check out:
> https://docs.kernel.org/process/5.Posting.html
> https://docs.kernel.org/process/submitting-patches.html
> https://docs.kernel.org/process/submit-checklist.html
> And there's more resources to check out in the Documentation/process directory.