Re: [PATCH] docs/xen-tscmode: remove mention of numeric tsc_mode= values

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Wed, Jul 19, 2023 at 08:24:15AM +0200, Jan Beulich wrote:
> On 18.07.2023 22:58, Elliott Mitchell wrote:
> > On Fri, Jul 14, 2023 at 09:21:59AM +0200, Jan Beulich wrote:
> >> On 14.07.2023 05:44, Elliott Mitchell wrote:
> >>> On Fri, Jul 14, 2023 at 03:24:59AM +0200, Marek Marczykowski-Górecki 
> >>> wrote:
> >>>> On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
> >>>>> The better to encourage moving to setting via string mode names.
> >>>>
> >>>> The numeric values needs to remain documented, otherwise interpreting
> >>>> pre-existing configs (that may use them) will be tricky.
> >>>
> >>> Problem is the way it is documented tends to encourage continued use of
> >>> the numeric values (notice how reports irt Zen 4 mention "tsc_mode=1").
> >>>
> >>> `parse_config_data()` suggests the appropriate string value, so nominally
> >>> that should take care of older configurations.  If "xen-tscmode" really
> >>> needs to continue mentioning the numeric value, it should be in
> >>> parentheses and with "old value" to suggest moving away from that.
> >>
> >> I'm not sure about "old" (we can't change the values without breaking
> >> backwards compatibility), but the numeric values will want mentioning
> >> alongside their spelled out names.
> > 
> > Then why is there a warning message about numeric tsc_mode in
> > `parse_config_data()`?
> 
> I'm afraid this question can only be answered by whoever was involved
> in adding the warning.

I already tracked that down, commit af3b530c03 by Ian Campbell.  Appears
Ian Campbell has moved onto other things and may not be readily
accessible.

The messages themselves seem to suggest >10 years ago Ian Campbell wanted
to get rid of the numeric values for tsc_mode.  Problem is one debug
string was left in and the documentation doesn't discourage the numeric
values.  As such they may still be heavily used.

What needs to happen is a decision of which direction to push needs to be
made.  Then that direction needs to be consistently pushed.

Notice the immediately prior message trying to get rid of the
printf-debugging.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445