All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: qemu-devel@nongnu.org, yang.zhong@intel.com, pbonzini@redhat.com,
	qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH] s390x: express dependencies with Kconfig
Date: Tue, 29 Jan 2019 10:08:25 +0100	[thread overview]
Message-ID: <2e112213-373a-4b88-7dba-c5dbd58aba5b@redhat.com> (raw)
In-Reply-To: <20190128170819.4998232d.cohuck@redhat.com>

On 2019-01-28 17:08, Cornelia Huck wrote:
> On Mon, 28 Jan 2019 16:29:26 +0100
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> Instead of hard-coding all config switches in the config file
>> default-configs/s390x-softmmu.mak, let's use the new Kconfig files
>> to express the necessary dependencies: The S390_CCW_VIRTIO config switch
>> for the "s390-ccw-virtio" machine now selects all non-optional devices.
>>
>> And since we already have the VIRTIO_PCI and VIRTIO_MMIO config switches
>> for the other two virtio transports, this patch also introduces a new
>> config switch VIRTIO_CCW for the third, s390x-specific virtio transport,
>> so that all three virtio transports are now handled in the same way.
> 
> I haven't found time to look at the Kconfig patches, so take the
> following with a generous amount of salt.
> 
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>  This goes on top of the curren Kconfig series:
>>
>>  Based-on: 1548410831-19553-1-git-send-email-pbonzini@redhat.com
>>
>>  default-configs/s390x-softmmu.mak | 12 ++++++++----
>>  hw/s390x/Kconfig                  |  4 ++++
>>  hw/s390x/Makefile.objs            |  2 +-
>>  hw/virtio/Kconfig                 |  4 ++++
>>  4 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/default-configs/s390x-softmmu.mak b/default-configs/s390x-softmmu.mak
>> index 2be5059..08b1683 100644
>> --- a/default-configs/s390x-softmmu.mak
>> +++ b/default-configs/s390x-softmmu.mak
>> @@ -1,9 +1,13 @@
>> -CONFIG_PCI=y
>> +# Default configuration for s390x-softmmu
>> +
>> +# Optional devices:
>> +#
>>  CONFIG_VIRTIO_PCI=y
>> -CONFIG_SCLPCONSOLE=y
>>  CONFIG_TERMINAL3270=y
>> -CONFIG_S390_FLIC=y
>>  CONFIG_WDT_DIAG288=y
>> -CONFIG_S390_CCW_VIRTIO=y
>>  CONFIG_VFIO_CCW=y
>>  CONFIG_VFIO_AP=y
> 
> This looks sensible.
> 
>> +
>> +# Boards:
>> +#
>> +CONFIG_S390_CCW_VIRTIO=y
>> diff --git a/hw/s390x/Kconfig b/hw/s390x/Kconfig
>> index 303db7f..9a36c39 100644
>> --- a/hw/s390x/Kconfig
>> +++ b/hw/s390x/Kconfig
>> @@ -1,2 +1,6 @@
>>  config S390_CCW_VIRTIO
>>      bool
>> +    select PCI
>> +    select S390_FLIC
>> +    select SCLPCONSOLE
>> +    select VIRTIO_CCW
> 
> This also makes sense. (I assume CONFIG_PCI, CONFIG_S390_FLIC, and
> CONFIG_SCLPCONSOLE are already defined in the base patch series.)

Yes, they are.

>> diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
>> index a884aae..0dc798a 100644
>> --- a/hw/s390x/Makefile.objs
>> +++ b/hw/s390x/Makefile.objs
>> @@ -8,7 +8,7 @@ obj-y += ipl.o
>>  obj-y += css.o
>>  obj-y += s390-virtio-ccw.o
>>  obj-y += 3270-ccw.o
> 
> Should this depend on TERMINAL3270 (at least in the future)?

Yes, this is related to TERMINAL3270 which is already used for
hw/char/terminal3270. So I think we could use $(CONFIG_TERMINAL3270)
here, too.

>> -obj-y += virtio-ccw.o
>> +obj-$(CONFIG_VIRTIO_CCW) += virtio-ccw.o
>>  obj-$(CONFIG_VIRTIO_SERIAL) += virtio-ccw-serial.o
> 
> Hm. Should the individual device types depend both on VIRTIO_<device>
> and on VIRTIO_CCW? Making VIRTIO_<device> depend on VIRTIO_PCI ||
> VIRTIO_CCW || VIRTIO_MMIO is probably not enough, as we could be trying
> to build virtio-ccw devices if only VIRTIO_PCI is set (or virtio-pci
> devices if only VIRTIO_CCW is set, for that matter.)

You're right, the whole section should be fenced via

ifeq ($(CONFIG_VIRTIO_CCW),y)
...
endif

I'll update my patch accordingly and send a v2.

 Thanks,
  Thomas

  reply	other threads:[~2019-01-29  9:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3f01a301-d639-dbe7-f522-42a50e2d443e@redhat.com>
2019-01-28 15:29 ` [Qemu-devel] [PATCH] s390x: express dependencies with Kconfig Thomas Huth
2019-01-28 16:08   ` [Qemu-devel] [qemu-s390x] " Cornelia Huck
2019-01-29  9:08     ` Thomas Huth [this message]
2019-01-29  9:42     ` [Qemu-devel] [PATCH v2] " Thomas Huth
2019-01-29  9:49       ` [Qemu-devel] [qemu-s390x] " Cornelia Huck
2019-01-29 10:07         ` Paolo Bonzini
2019-01-29 11:02           ` Yang Zhong
2019-01-30  9:43 ` [Qemu-devel] [RFC PATCH 0/5] Kconfig dependencies for ppc machines Thomas Huth
2019-01-30  9:43   ` [Qemu-devel] [RFC PATCH 1/5] ppc64: Express dependencies of 'pseries' and 'powernv' machines with kconfig Thomas Huth
2019-01-30  9:57     ` Paolo Bonzini
2019-01-30 10:02       ` Thomas Huth
2019-01-30 10:15         ` Paolo Bonzini
2019-01-30 11:00     ` Cédric Le Goater
2019-01-30 11:04       ` Thomas Huth
2019-01-30 11:12         ` Cédric Le Goater
2019-01-30  9:43   ` [Qemu-devel] [RFC PATCH 2/5] ppc: Express dependencies of the 'prep' and '40p' " Thomas Huth
2019-01-30 10:17     ` Paolo Bonzini
2019-01-30 10:25       ` Thomas Huth
2019-01-30 11:02         ` Thomas Huth
2019-01-30 11:10           ` Paolo Bonzini
2019-01-30 11:09         ` Paolo Bonzini
2019-01-30  9:43   ` [Qemu-devel] [RFC PATCH 3/5] ppc: Express dependencies of the Mac " Thomas Huth
2019-01-30 10:18     ` Paolo Bonzini
2019-01-30 17:13     ` Mark Cave-Ayland
2019-01-30 17:21       ` Paolo Bonzini
2019-01-31  5:23       ` Thomas Huth
2019-01-30  9:43   ` [Qemu-devel] [RFC PATCH 4/5] ppc: Express dependencies of the Sam460EX " Thomas Huth
2019-01-30 10:18     ` Paolo Bonzini
2019-01-30 11:29     ` BALATON Zoltan
2019-01-30 12:03       ` Thomas Huth
2019-01-30  9:43   ` [Qemu-devel] [RFC PATCH 5/5] ppc: Express dependencies of the embedded " Thomas Huth
2019-01-30 10:18     ` Paolo Bonzini
2019-01-30 10:59   ` [Qemu-devel] [RFC PATCH 0/5] Kconfig dependencies for ppc machines Yang Zhong

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=2e112213-373a-4b88-7dba-c5dbd58aba5b@redhat.com \
    --to=thuth@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=yang.zhong@intel.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.