On Wed, Feb 19, 2020 at 01:21:10PM +0100, Julia Suvorova wrote: > On Wed, Feb 19, 2020 at 4:47 AM Michael S. Tsirkin <m...@redhat.com> wrote: > > > > On Tue, Feb 18, 2020 at 10:02:19PM -0500, Laine Stump wrote: > > > Also, is there a rhyme/reason for some options having true/false, and some > > > being off/on? disable-acs seems to be true/false, but disable-modern is > > > on/off. Doesn't make any difference to me in the end, but just thought I'd > > > bring it up in case there might be a reason to use on/off instead of > > > true/false for this one. > > > > Some places accept on/off, some true/false, some on/off/true/false > > others on/off/yes/no and others on/off/true/false/yes/no. > > > > In this case both user visitor machinery. Which I *think* > > means on/off is the safe choice and true/false can be > > broken in some places. > > > > We really should clean up this mess ... Julia, what do you think? > > Let's make them all support all options? > > Options already support all of on/off/true/false/yes/no as long as > they are defined as boolean (look at parse_type_bool()). That is, you > can use disable-modern with yes/no/true/false too. > The only problem is with types OnOffSplit and OnOffAuto (as in > disable-legacy).
Right. Not only that though - parse_option_bool can only handle on/off. target/sparc/cpu.c can handle on/off and true/false. JSON bool is only true/false. As you said OnOffSplit and OnOffAuto are on/off. And from documentation POV, it's all over the place. -- MST