Re: [PATCH 5/5] hw/core: Remove transitional infrastructure from BusClass

[Peter Maydell]

On Wed, 31 Jan 2024 at 03:44, Zhao Liu <zhao1.liu@intel.com> wrote:
>
> On Fri, Jan 19, 2024 at 04:35:12PM +0000, Peter Maydell wrote:
> > Date: Fri, 19 Jan 2024 16:35:12 +0000
> > From: Peter Maydell <peter.maydell@linaro.org>
> > Subject: [PATCH 5/5] hw/core: Remove transitional infrastructure from
> >  BusClass
> > X-Mailer: git-send-email 2.34.1
> >
> > BusClass currently has transitional infrastructure to support
> > subclasses which implement the legacy BusClass::reset method rather
> > than the Resettable interface.  We have now removed all the users of
> > BusClass::reset in the tree, so we can remove the transitional
> > infrastructure.
> >
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > ---
> >  include/hw/qdev-core.h |  2 --
> >  hw/core/bus.c          | 67 ------------------------------------------
> >  2 files changed, 69 deletions(-)
>
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
>
> It seems the similar cleanup for DeviceClass needs a lot of effort.

Yes and no. It's true that there are a lot of DeviceClass
subclasses that implement the legacy reset method still.
However, they are all "leaf" classes which provide a single
reset method, and don't need to either chain up to a parent
class reset implementation or allow a child class to
inherit from them. So they don't affect any other classes
in the system or block any other classes from being able
to use a full three-phase reset. So I'm not too worried
if we continue to have a lot of these leaf classes: the
old reset method is then just a different way of having
a device with a reset 'hold' method and no others.

I did an earlier round of refactoring back in 2022 that did
the cleanup of the non-leaf classes and the classes that
need to chain up to their parent class reset, which mostly
updated all of that kind of class to 3-phase. The one
exception is that we still have a single user of
device_class_set_parent_reset() in the s390 CPU, which
is awkward to deal with because it interacts with an
s390-specific handling of different levels of reset.

I also want to look at providing a 3-phase equivalent
of the qdev_register_reset() API at some point: that one
is definitely blocking some useful improvements, including
dealing with the vfio ordering issue, and also would let
me clean up some M-profile ARM CPU reset hacks.

thanks
-- PMM