On Tue, May 17, 2016 at 03:39:14PM +0800, Cao jin wrote: > > > On 05/15/2016 09:25 PM, Marcel Apfelbaum wrote: > >On 05/06/2016 07:20 AM, Cao jin wrote: > >> From bit to enum OnOffAuto. > >> > >>cc: Michael S. Tsirkin <m...@redhat.com> > >>cc: Markus Armbruster <arm...@redhat.com> > >>cc: Marcel Apfelbaum <mar...@redhat.com> > >>Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> > >>--- > >> > >>Actually, I am not quite sure this device need this change, RFC. > >> > > > >Well, it already has the 'msi' property, so we may want to make it > >standard 'OnOffAuto'. > >One problem I can see is the change of semantics. Until now msi=on means > >'auto'. From now on > >it means 'force msi=on', fail otherwise. If I got this right, old > >machines having msi=on > >will failed to start on platforms with msibroken=true, right? > > Exactly, and patch 11 indeed has semantics change. According to what we > discussed before: "if user want msi=on explicitly on command line, then > msi_init`s failure should result in failing to create device", this > semantics change seems can`t be avoid. > > >Maybe we should preserve the semantics for old machines? (this patch > >does not actually > >affect the semantics, but patch 11/11 should, otherwise why change it to > >OnOffAuto, right? ) > > IMHO, in this case, keep compat maybe a burden on us, and make command-line > confusing. See my understanding: > > before: > command line format is msi=on/off, and 'on' means auto > > now: > we change command line to msi=on/off/auto, and keep compat is meaning 'on' > still means auto? If so, why need 'auto' > > So, I am thinking, maybe we can help old machine user update their > configuration, I mean: when they set msi=on on platforms with > msibroken=true, they definitely fail, so we should give a clear hint in > error message to help them know what should do to start the machine, like > "please use msi=auto and try again"
Personally I don't consider this a big issue. I don't think many people specify msi=on. > -- > Yours Sincerely, > > Cao jin >
