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"
--
Yours Sincerely,
Cao jin
