On Thu, 27 Apr 2017 20:23:51 +0800
Zihan Yang <tgny...@gmail.com> wrote:

> OK, sorry for the confusion, I will give a new patch series. I'm not very
> familiar with
> the conventions so I wonder if someone could help clarify some principles
> for me.
> I'd like to replace all the init/exit callback of DeviceClass to
> realize/unrealize,  and
> convert return type of exit callback of some higher-level classes, like
> HDACodecDeviceClass, to void.
> 
> My first question Is it a good idea to split these patches into two series?
> For example,
> one series to convert exit callback of these higher-level classes to void,
> and then the
> other to replace all the init/exit callback of DeviceClass to
> realize/unrealize.

This is probably a good idea: converting exit callbacks to void is
relatively straightforward, while converting to realize/unrealize might
be better done while revisiting some of the modelling of the relevant
subsystems. (For example, all classes for virtio-ccw use the same exit
callback - it might be a good idea to do the same work in a common
unrealize function when you touch it anyway.)

> 
> The second question is that should I always give separate patch for
> different directories?
> One  example is that in both hw/ide and hw/block, I need to replace the
> init callback with
> realize in some high-level classes, should I give two patches or just give
> one patch for
> the work?

A better way to split is along maintainership responsibilites (which
may or may not align with directories). Again, sticking with the code I
maintain, I would merge changes to hw/char/sclp* and hw/s390x/, but not
to other code in hw/char/. Try to stick to logical units (continuing
with that example, different patches for sclp and virtio-ccw would make
sense).

The most important thing to remember when splitting changes is that you
need to preserve bisectability, i.e. every step in your patch series
needs to compile.


Reply via email to