From: Thomas Huth <thuth@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-s390x@nongnu.org, Collin Walling <walling@linux.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] hw/s390x: Fix the function arguments in the pci stub file
Date: Mon, 11 Feb 2019 11:54:45 +0100 [thread overview]
Message-ID: <746bc346-26ce-e096-d8a4-fe78bf7912c1@redhat.com> (raw)
In-Reply-To: <20190211114859.76109aa3.cohuck@redhat.com>
On 2019-02-11 11:48, Cornelia Huck wrote:
> On Fri, 1 Feb 2019 09:23:56 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
>
>> On Fri, 1 Feb 2019 07:46:40 +0100
>> Thomas Huth <thuth@redhat.com> wrote:
>
>>> So I see two options now:
>>>
>>> 1) Finally really make the device optional, at least for new machine
>>> types, so we can really disable CONFIG_PCI and get a working executable.
>>>
>>> 2) Scratch the idea completely to make this optional, always link the
>>> s390-pci-bus.o and s390-pci-inst.o files unconditionally, and remove the
>>> s390-pci-stub.c file.
>>>
>>> I assume options 2 is preferred, since we likely rather want to move
>>> into the PCI direction in the long run, instead of ignoring it...
>>
>> I think both options are viable, but option 1 is of course more work.
>> The win there is that we could disable an entire subsystem.
>>
>> I guess that the basic questions are: How important is it that
>> subsystems can be compiled out, and do we see a use case for a pci-less
>> s390 machine in the future? We really don't want to spend much time on
>> something of dubious use...
>
> Any thoughts on this?
>
> I'm currently tending towards option 2 (and can cook up a patch for
> that). Unless someone is already working on option 1 :)
Since nobody currently has a need to completely disable PCI, I think we
should go with option 2.
Thomas
next prev parent reply other threads:[~2019-02-11 10:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 17:47 [Qemu-devel] [PATCH] hw/s390x: Fix the function arguments in the pci stub file Thomas Huth
2019-01-31 17:56 ` Cornelia Huck
2019-01-31 18:00 ` Thomas Huth
2019-01-31 18:08 ` Paolo Bonzini
2019-02-01 6:14 ` Thomas Huth
2019-02-01 6:46 ` Thomas Huth
2019-02-01 8:23 ` Cornelia Huck
2019-02-11 10:48 ` Cornelia Huck
2019-02-11 10:54 ` Thomas Huth [this message]
2019-02-11 11:04 ` Cornelia Huck
2019-02-11 11:17 ` Thomas Huth
2019-02-11 11:20 ` Cornelia Huck
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=746bc346-26ce-e096-d8a4-fe78bf7912c1@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=walling@linux.ibm.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.