From: Bin Meng <bmeng.cn@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Markus Carlstedt" <markus.carlstedt@windriver.com>,
"Jason Wang" <jasowang@redhat.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"Christina Wang" <christina.wang@windriver.com>
Subject: Re: [PATCH v2 1/3] hw/net: e1000: Correct the initial value of VET register
Date: Wed, 14 Jul 2021 17:14:23 +0800 [thread overview]
Message-ID: <CAEUhbmWZnkUKG76SWi0bOXDta9eR__Z5zn38UjSMROuucc1jQg@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA_5LugG0JbBX=gN=dYE301nVNuDUpe9--_8o3rw9_y4Jg@mail.gmail.com>
On Wed, Jul 14, 2021 at 5:01 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 14 Jul 2021 at 04:42, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <jasowang@redhat.com> wrote:
> > >
> > >
> > > 在 2021/7/13 下午5:11, Bin Meng 写道:
> > > > Can we get some agreement among maintainers?
> > >
> > >
> > > It's not about the agreement but about to have a stable ABI. I don't
> > > know the case for sd but e1000 is used in various and we work hard to
> > > unbreak the migration compatibility among downstream versions. Git log
> > > on e1000.c will tell you more.
> >
> > Agreement or stable ABI, whatever we call, but we should be in some consistency.
> >
> > IMHO maintainers should reach an agreement to some extent on how
> > compatibility should be achieved. I just found silly to add a property
> > to fix a real bug in the model, and we preserve the bug all over
> > releases.
> >
> > I can find plenty of examples in the current QEMU tree that were
> > accepted that changed the bugous register behavior, but it was not
> > asked to add new properties to keep the bugos behavior.
> >
> > e.g.: commit ce8e43760e8e ("hw/net: fsl_etsec: Reverse the RCTRL.RSF logic")
>
> There is basically a judgement call going on here about whether the
> device is "significant enough" that it's worth the effort of
> preserving back-compatibility of bugs.
>
> There is at least one clear rule: if the device isn't used by any
> machine with a versioned machine type, then there is no need to
> provide back-compatibility of old buggy behaviour. (There would
> be no way for the user to select the old behaviour by choosing a
> -4.2 machine type.) This is why the fsl_etsec device doesn't need
> to handle that.
>
> For PCI devices it's a bit fuzzier because in theory you can plug
> any PCI card into a versioned x86 PC machine.
>
> We don't want to preserve bug-compatibility for absolutely
> everything, because the codebase would quickly clog up with weird
> behaviour that we never test and which is not of any use to users
> either. So you have to look at:
> * how easy is providing the back-compat?
> * how commonly used in production is the device?
> * how likely is it that guests might care?
> * would the behaviour change cause odd behaviour across
> a cross-version migration from the old QEMU?
>
> Migration compat is similar, but not quite the same because the
> compatibility handling tends to be less invasive, so we take the
> "provide compat" choice more often. For non-versioned machine types,
> again, we're OK with breaking back-compat as long as we bump a
> migration version number so the user gets an error message rather
> than weird behaviour.
Thanks Peter. I think the above information can be put in a doc in
docs/devel, and with some real examples to help developers on how to
achieve backward compatibility.
Regarding this series, as I mentioned in an earlier thread, I believe
the possibility of breaking a guest is very low. Adding a back-compat
check is not that hard either. Just not sure which factor weighs more.
Regards,
Bin
next prev parent reply other threads:[~2021-07-14 9:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 9:24 [PATCH v2 1/3] hw/net: e1000: Correct the initial value of VET register Bin Meng
2021-07-02 9:24 ` [PATCH v2 2/3] hw/net: e1000e: " Bin Meng
2021-07-02 9:24 ` [PATCH v2 3/3] hw/net: e1000e: Don't zero out the VLAN tag in the legacy RX descriptor Bin Meng
2021-07-05 4:21 ` [PATCH v2 1/3] hw/net: e1000: Correct the initial value of VET register Jason Wang
2021-07-05 5:57 ` Bin Meng
2021-07-12 23:06 ` Bin Meng
2021-07-13 7:03 ` Jason Wang
2021-07-13 8:36 ` Bin Meng
2021-07-13 9:02 ` Jason Wang
2021-07-13 9:11 ` Bin Meng
2021-07-14 3:10 ` Jason Wang
2021-07-14 3:42 ` Bin Meng
2021-07-14 4:53 ` Jason Wang
2021-07-14 6:04 ` Bin Meng
2021-07-14 8:40 ` Jason Wang
2021-07-14 9:05 ` Bin Meng
2021-07-14 9:17 ` Jason Wang
2021-07-14 9:00 ` Peter Maydell
2021-07-14 9:14 ` Bin Meng [this message]
2021-07-14 9:24 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEUhbmWZnkUKG76SWi0bOXDta9eR__Z5zn38UjSMROuucc1jQg@mail.gmail.com \
--to=bmeng.cn@gmail.com \
--cc=bin.meng@windriver.com \
--cc=christina.wang@windriver.com \
--cc=f4bug@amsat.org \
--cc=jasowang@redhat.com \
--cc=markus.carlstedt@windriver.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).