[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED
On Tue, Jan 26, 2021 at 01:20:14PM +0000, Bertrand Marquis wrote: > > > > On 26 Jan 2021, at 13:19, Jan Beulich <jbeulich@xxxxxxxx> wrote: > > > > On 26.01.2021 14:17, Ian Jackson wrote: > >> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce > >> UNSUPPORTED"): > >>> On 26.01.2021 12:17, Bertrand Marquis wrote: > >>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT > >>>> config parameters instead ? > >>>> We could also make that more clear in the help of such parameters > >>>> directly. > >>>> > >>>> I do not see how we could make that more clear directly in the prompt (as > >>>> making it too long is not a good solution). > >>> > >>> My main request is that such tags be added only if there's > >>> absolutely no ambiguity. Anything else (requiring longer > >>> explanations in many cases) should be expressed in the help > >>> text of the option, or in yet other ways (a referral to > >>> SUPPORT.md comes to mind). > >> > >> Is > >> > >>>>>>> + bool "Harden the branch predictor against aliasing attacks > >>>>>>> (disabling UNSUPPORTED)" if UNSUPPORTED > >> > >> too long ? > > > > It may be tolerable, but it is getting longish imo. > > I am also not quite sure this is making things clearer. IMO it the original version strongly suggested that _enabling_ the option is unsupported (and quite confusing why it was enabled by default). When browsing the menu, it isn't really clear what is the default value, and even if it would be, it's totally not obvious that the meaning of "(UNSUPPORTED)" depends on default option value. So, yes, I think "(disabling UNSUPPORTED)" is significantly better for such cases. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab Attachment:
signature.asc
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |