All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Zihan Yang <tgnyang@gmail.com>
Cc: Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 1/5] hw/char: remove console_exit function in sclp
Date: Thu, 27 Apr 2017 16:03:03 +0200	[thread overview]
Message-ID: <20170427160303.04250bf6.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <CAPnP68gpK8zzOo+g9cc6YZsQoHabH3hY4aKMXcB7b=RAitZQAw@mail.gmail.com>

On Thu, 27 Apr 2017 20:23:51 +0800
Zihan Yang <tgnyang@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	other threads:[~2017-04-27 14:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26 12:53 [Qemu-devel] [PATCH 1/5] hw/char: remove console_exit function in sclp Zihan Yang
2017-04-26 12:53 ` [Qemu-devel] [PATCH 2/5] hw/s390x: make virtio_ccw_exit function in virtio-ccw return void Zihan Yang
2017-04-26 12:53 ` [Qemu-devel] [PATCH 3/5] hw/s390: convert exit to unrealize in virtio_ccw_device_class_init Zihan Yang
2017-04-26 12:53 ` [Qemu-devel] [PATCH 4/5] hw/audio: replace exit with unrealize in hda_codec_device_class_init Zihan Yang
2017-04-26 12:53 ` [Qemu-devel] [PATCH 5/5] hw/audio: convert exit callback in HDACodecDeviceClass to void Zihan Yang
2017-04-26 14:42 ` [Qemu-devel] [PATCH 1/5] hw/char: remove console_exit function in sclp Eric Blake
2017-04-26 15:05   ` Cornelia Huck
2017-04-27 12:23     ` Zihan Yang
2017-04-27 14:03       ` Cornelia Huck [this message]

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=20170427160303.04250bf6.cornelia.huck@de.ibm.com \
    --to=cornelia.huck@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=eblake@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=tgnyang@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.