Re: [Intel-gfx] [PATCH v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers

[Jani Nikula]

On Tue, 01 Oct 2019, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 01, 2019 at 12:42:34PM +0300, Jani Nikula wrote:
>> On Tue, 01 Oct 2019, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, Oct 01, 2019 at 11:07:39AM +0300, Jani Nikula wrote:
>> >> The kernel has plenty of ternary operators to choose between constant
>> >> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
>> >> "s":
>> >> 
>> >> $ git grep '? "yes" : "no"' | wc -l
>> >> 258
>> >> $ git grep '? "on" : "off"' | wc -l
>> >> 204
>> >> $ git grep '? "enabled" : "disabled"' | wc -l
>> >> 196
>> >> $ git grep '? "" : "s"' | wc -l
>> >> 25
>> >> 
>> >> Additionally, there are some occurences of the same in reverse order,
>> >> split to multiple lines, or otherwise not caught by the simple grep.
>> >> 
>> >> Add helpers to return the constant strings. Remove existing equivalent
>> >> and conflicting functions in i915, cxgb4, and USB core. Further
>> >> conversion can be done incrementally.
>> >> 
>> >> While the main goal here is to abstract recurring patterns, and slightly
>> >> clean up the code base by not open coding the ternary operators, there
>> >> are also some space savings to be had via better string constant
>> >> pooling.
>> >> 
>> >> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
>> >> Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
>> >> Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx
>> >> Cc: Vishal Kulkarni <vishal@xxxxxxxxxxx>
>> >> Cc: netdev@xxxxxxxxxxxxxxx
>> >> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>> >> Cc: linux-usb@xxxxxxxxxxxxxxx
>> >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> >> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> >> Cc: Julia Lawall <julia.lawall@xxxxxxx>
>> >> Cc: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
>> >> Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> # v1
>> >
>> > As this is a totally different version, please drop my reviewed-by as
>> > that's really not true here :(
>> 
>> I did indicate it was for v1. Indeed v2 was different, but care to
>> elaborate what's wrong with v3?
>
> No idea, but I haven't reviewed it yet, so to put my tag on there isn't
> the nicest...

Apologies, no harm intended.

At times, I've seen the "# vN" notation used, I suppose both to indicate
that the *ideas* presented in the earlier version warranted Reviewed-by
from so-and-so, though this particular version still needs detailed
review, and that the approval of the reviewer of the earlier version
should be sought out before merging a subsequent version.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center