Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/4] spapr:DRC cleanups (part I)

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

On Thu, Jun 01, 2017 at 12:41:40PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 06/01/2017 02:30 AM, David Gibson wrote:
> > On Wed, May 31, 2017 at 11:25:41PM -0500, Michael Roth wrote:
> > > Quoting Bharata B Rao (2017-05-31 23:06:46)
> > > > On Thu, Jun 01, 2017 at 11:52:14AM +1000, David Gibson wrote:
> > > > > The code managing DRCs[0] has quite a few things that are more
> > > > > complicated than they need to be.  In particular the object
> > > > > representing a DRC has a bunch of method pointers, despite the fact
> > > > > that there are currently no subclasses, and even if there were the
> > > > > method implementations would be unlikely to differ.
> > > > So you are getting rid of a few methods. How about other methods ?
> > > > Specially attach and detach which have incorporated all the logic needed
> > > > to handle logical and physical DRs into their implementations ?
> > > I would avoid any methods that incorporate special-casing for
> > > physical vs. logical DRCs, since that seems like a good logical
> > > starting point for moving to 'physical'/'logical' DRC
> > > sub-classes to help simplify the increasingly complicated
> > > state-tracking.
> > Right, I'm looking at making subclasses for each of the DRC types.
> > Possibly with intermediate subclasses for physical vs. logical, we'll
> > see how it works out.
> 
> Back in the DRC migration patch series I talked with Mike about refactoring
> the DRC code in such fashion (physical DRC and logical DRC). But first I
> would
> implement some kind of unit testing in this code to avoid breaking too much
> stuff during this refactoring.

So, I'd love to have good unit tests, but everything takes time.

> I am not sure about the effort to implementing unit test in the
> current DRC code.  This series is simplifying the DRC code, making
> it more minimalist and possibly easier to be tested. In the end it
> would be a first step towards unit testing.

..and as you say, extra complexity in the code makes testing and
reliability harder.

> 
> However, there is the issue of backward compatibility. I fear this DRC
> refactoring
> of Logical/Physical DRC would be too drastic to maintain such compatibility
> (assuming that it is not already broken). If this refactor goes live only in
> 2.11 then
> we will have a hard time to migrate from 2.11 to 2.10.

Right such a rework could break migration.

> All that said, I believe we can live without unit testing for a little
> longer and if
> we're going for this Physical/DRC refactoring, we need to push it for 2.10.
> We can
> think about unit test later with the refactored code. Feel free to send to
> me any
> unfinished/beta DRC refactoring code you might be working on and want
> tested. I can help in the refactoring too, just let me know.

So like you I think getting it into 2.10 would be a good idea, before
we have any released version with DRC migration to break.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]