On 13/12/18 12:50, Yang Zhong wrote:
> Hello Paolo and all,
>
> The Kconfig has been completed the porting from your repo and
> now i can sucessfully build x86_64-softmmu binary. But there
> are still some issues:
>1) Only support x86_64 platform.
> Other platform, especially for ARM
Hello Paolo and all,
The Kconfig has been completed the porting from your repo and
now i can sucessfully build x86_64-softmmu binary. But there
are still some issues:
1) Only support x86_64 platform.
Other platform, especially for ARM platforms, it's hard for me to define
detailed
On 09/11/2018 20:16, Eduardo Habkost wrote:
> On Fri, Nov 09, 2018 at 11:10:21AM +0100, Paolo Bonzini wrote:
>> On 08/11/2018 22:00, Eduardo Habkost wrote:
>>> Understood. My interpretation of "target" was just "a QEMU
>>> binary". In other words, I thought we were talking about
>>> anything
On Fri, Nov 09, 2018 at 11:10:21AM +0100, Paolo Bonzini wrote:
> On 08/11/2018 22:00, Eduardo Habkost wrote:
> > Understood. My interpretation of "target" was just "a QEMU
> > binary". In other words, I thought we were talking about
> > anything that could be compiled in/out from a specific QEMU
On 08/11/2018 22:00, Eduardo Habkost wrote:
> Understood. My interpretation of "target" was just "a QEMU
> binary". In other words, I thought we were talking about
> anything that could be compiled in/out from a specific QEMU
> binary.
The idea is "target" as opposed to "host".
> Do you have a
On Thu, Nov 08, 2018 at 09:28:06PM +0100, Paolo Bonzini wrote:
> Oops. :)
>
> On 08/11/2018 19:42, Eduardo Habkost wrote:
> >>> Keeping in mind that I might be talking about extra challenges we
> >>> won't address right now (no cart before the horse), I have new
> >>> questions:
> >>>
> >>> Why
Oops. :)
On 08/11/2018 19:42, Eduardo Habkost wrote:
>>> Keeping in mind that I might be talking about extra challenges we
>>> won't address right now (no cart before the horse), I have new
>>> questions:
>>>
>>> Why you say backends are not a target configuration and
>>> accelerators are?
On Thu, Nov 08, 2018 at 06:58:11PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 18:14, Eduardo Habkost wrote:
> > Keeping in mind that I might be talking about extra challenges we
> > won't address right now (no cart before the horse), I have new
> > questions:
> >
> > Why you say backends are not
On 08/11/2018 18:14, Eduardo Habkost wrote:
> Keeping in mind that I might be talking about extra challenges we
> won't address right now (no cart before the horse), I have new
> questions:
>
> Why you say backends are not a target configuration and
> accelerators are? What's the definition of
On Thu, Nov 08, 2018 at 02:42:19PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 14:06, Eduardo Habkost wrote:
> > On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote:
> >> On 07/11/2018 20:30, Thomas Huth wrote:
> >>> On 2018-11-07 20:24, Eduardo Habkost wrote:
> On Wed, Nov 07, 2018
On 08/11/2018 14:06, Eduardo Habkost wrote:
> On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote:
>> On 07/11/2018 20:30, Thomas Huth wrote:
>>> On 2018-11-07 20:24, Eduardo Habkost wrote:
On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> On 07/11/2018 16:41,
On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote:
> On 07/11/2018 20:30, Thomas Huth wrote:
> > On 2018-11-07 20:24, Eduardo Habkost wrote:
> >> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> >>> On 07/11/2018 16:41, Samuel Ortiz wrote:
> - The Kconfig parser
Paolo Bonzini writes:
> On 08/11/2018 09:46, Philippe Mathieu-Daudé wrote:
>>
>> Almost; if there's a conflict between the decision from "depends on" and
>> "select" says, it's an error. (Likewise if there's a conflict between
>> default-configs/ on one side, and "depends
On 08/11/2018 11:14, Thomas Huth wrote:
> On 2018-11-08 10:55, Paolo Bonzini wrote:
>> On 07/11/2018 20:30, Thomas Huth wrote:
>>> On 2018-11-07 20:24, Eduardo Habkost wrote:
On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> On 07/11/2018 16:41, Samuel Ortiz wrote:
>> -
On Wed, Nov 07, 2018 at 05:24:14PM -0200, Eduardo Habkost wrote:
> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> > On 07/11/2018 16:41, Samuel Ortiz wrote:
> > > - The Kconfig parser would be used to generate the equivalent of what we
> > > currently have under
Le jeu. 8 nov. 2018 11:30, Thomas Huth a écrit :
> On 2018-11-08 10:55, Paolo Bonzini wrote:
> > On 07/11/2018 20:30, Thomas Huth wrote:
> >> On 2018-11-07 20:24, Eduardo Habkost wrote:
> >>> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> On 07/11/2018 16:41, Samuel Ortiz
On 2018-11-08 10:55, Paolo Bonzini wrote:
> On 07/11/2018 20:30, Thomas Huth wrote:
>> On 2018-11-07 20:24, Eduardo Habkost wrote:
>>> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
On 07/11/2018 16:41, Samuel Ortiz wrote:
> - The Kconfig parser would be used to generate
On 08/11/2018 09:46, Philippe Mathieu-Daudé wrote:
>
> Almost; if there's a conflict between the decision from "depends on" and
> "select" says, it's an error. (Likewise if there's a conflict between
> default-configs/ on one side, and "depends on"/"select" on the other).
>
>
On 07/11/2018 20:30, Thomas Huth wrote:
> On 2018-11-07 20:24, Eduardo Habkost wrote:
>> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
>>> On 07/11/2018 16:41, Samuel Ortiz wrote:
- The Kconfig parser would be used to generate the equivalent of what we
currently have
Le 26 sept. 2018 6:58 PM, "Paolo Bonzini" a écrit :
On 26/09/2018 16:15, Samuel Ortiz wrote:
> On Wed, Sep 26, 2018 at 03:36:07PM +0200, Paolo Bonzini wrote:
>> On 26/09/2018 10:32, Peter Maydell wrote:
>>> On 25 September 2018 at 10:26, Paolo Bonzini
wrote:
However, the Kconfig language
On 2018-11-07 20:24, Eduardo Habkost wrote:
> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
>> On 07/11/2018 16:41, Samuel Ortiz wrote:
>>> - The Kconfig parser would be used to generate the equivalent of what we
>>> currently have under default-configs/
I think we would still
On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> On 07/11/2018 16:41, Samuel Ortiz wrote:
> > - The Kconfig parser would be used to generate the equivalent of what we
> > currently have under default-configs/
>
> It would be used to generate config-devices.mak, instead of
>
On 07/11/2018 16:41, Samuel Ortiz wrote:
> - The Kconfig parser would be used to generate the equivalent of what we
> currently have under default-configs/
It would be used to generate config-devices.mak, instead of
scripts/make_device_config.sh. My branch already had some Makefile
Hi Paolo,
On Thu, Sep 27, 2018 at 10:55:59AM +0200, Paolo Bonzini wrote:
> > What is the syntactic thing in this example which distinguishes
> > "user can toggle this" (ESP_PCI, ARM_VIRT, SUN4M) from "user
> > can't toggle this, it's just an internal thing selected by
> > other nodes" (the rest)
On 26/09/2018 21:57, Peter Maydell wrote:
> On 26 September 2018 at 14:36, Paolo Bonzini wrote:
>> Here is a minimal example:
>>
>> # hw/scsi/Kconfig
>> config SCSI
>>
>> config ESP
>> select SCSI
>>
>> config ESP_PCI
>> default y
>> select ESP
>> depends on PCI
>>
>> #
On 26 September 2018 at 14:36, Paolo Bonzini wrote:
> Here is a minimal example:
>
> # hw/scsi/Kconfig
> config SCSI
>
> config ESP
> select SCSI
>
> config ESP_PCI
> default y
> select ESP
> depends on PCI
>
> # hw/pci/Kconfig
> config PCI
>
> # hw/pci-host/Kconfig
> config
On 26/09/2018 16:15, Samuel Ortiz wrote:
> On Wed, Sep 26, 2018 at 03:36:07PM +0200, Paolo Bonzini wrote:
>> On 26/09/2018 10:32, Peter Maydell wrote:
>>> On 25 September 2018 at 10:26, Paolo Bonzini wrote:
However, the Kconfig language is a good idea. The idea is that
dependencies can
On Wed, Sep 26, 2018 at 03:36:07PM +0200, Paolo Bonzini wrote:
> On 26/09/2018 10:32, Peter Maydell wrote:
> > On 25 September 2018 at 10:26, Paolo Bonzini wrote:
> >> However, the Kconfig language is a good idea. The idea is that
> >> dependencies can be expressed:
> >>
> >> - as "select"
On 26/09/2018 10:32, Peter Maydell wrote:
> On 25 September 2018 at 10:26, Paolo Bonzini wrote:
>> However, the Kconfig language is a good idea. The idea is that
>> dependencies can be expressed:
>>
>> - as "select" whenever a board requires a device, or whenever a device
>> requires generic
On 25 September 2018 at 10:26, Paolo Bonzini wrote:
> However, the Kconfig language is a good idea. The idea is that
> dependencies can be expressed:
>
> - as "select" whenever a board requires a device, or whenever a device
> requires generic subsystem code in order to implement a controller
Hi Paolo,
On Tue, Sep 25, 2018 at 11:26:36AM +0200, Paolo Bonzini wrote:
> Hi Samuel!
>
> On 25/09/2018 10:30, Thomas Huth wrote:
> > On 2018-09-24 11:21, Samuel Ortiz wrote:
> >> - Are there any fundamental reasons why the QEMU maintainers think that
> >> Kconfig would not fit QEMU's
Hi Samuel!
On 25/09/2018 10:30, Thomas Huth wrote:
> On 2018-09-24 11:21, Samuel Ortiz wrote:
>> - Are there any fundamental reasons why the QEMU maintainers think that
>> Kconfig would not fit QEMU's configuration requirements?
Kconfig itself is not a very good fit for QEMU's requirements
On 2018-09-24 11:21, Samuel Ortiz wrote:
> Hi All,
>
> It seems that back in 2013, Paolo tried to start a GSoC project [1]
> aimed at integrating Kconfig into QEMU and use it as its main
> configuration framework.
>
> I personally think that the rationale described in this GSoC project
> is
Hi All,
It seems that back in 2013, Paolo tried to start a GSoC project [1]
aimed at integrating Kconfig into QEMU and use it as its main
configuration framework.
I personally think that the rationale described in this GSoC project
is still valid today. However I'm not sure the project even
34 matches
Mail list logo
