[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU and Kconfig
From: |
Samuel Ortiz |
Subject: |
Re: [Qemu-devel] QEMU and Kconfig |
Date: |
Wed, 26 Sep 2018 12:20:09 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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 configuration requirements?
>
> Kconfig itself is not a very good fit for QEMU's requirements because
> QEMU builds multiple binaries, each with its own configuration.
> Therefore, the Kconfig mechanism for interactive configuration brings a
> lot of baggage that is (at least currently) useless for QEMU.
>
> 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 for
> that subsystem (e.g.: PC selects MC146818RTC, VIRTIO_SCSI selects SCSI)
>
> - as "depends on" whenever a device requires a bus (e.g.: SERIAL_PCI
> depends on ISA)
Agreed. I also agree with the fact that what we want is the language,
or even maybe a subset of it, not the actual configuration
framework/scripts/binaries.
> Putting the two things together, AHCI depends on PCI but it selects IDE.
>
> In the GSoC project we decided to rewrite it in Python. Unfortunately I
> lost the student's code, but I had also rewritten everything about 3
> years ago for a prototype and the result was not too shabby, less than
> 700 lines of code.
>
> >> - Are there other efforts currently going on for improving QEMU's
> >> configuration framework?
>
> No, but we were also thinking of resurrecting the project.
Ok, I guess we should coordinate here. Soon I'll be able to confirm if
we can put some resources on this, I'll let you know.
> > Hi,
> >
> > thanks for your interest! As far as I know, the project never started
> > (but Paolo might know more here). There are currently some efforts going
> > on to make the build process a little bit more flexible, but it's rather
> > about improving the usage of the various CONFIG_xxx flags (see e.g. the
> > recent changes to tests/Makefile.include), and not about replacing the
> > "configure" scripts and Makefiles with an alternative system.
>
> That was not the purpose of the project either. As you say below,
> Kconfig would be a replacement/improvement for the default-configs
> mechanism rather than the "./configure && make" mechanism. In addition,
> the project did not deal with removing backends.
>
> I pushed the latest state of the project to my github repo
> git://github.com/bonzini/bonzini, in branch kconfig. It's only 3 years
> old. :)
for the record, I think you meant: git://github.com/bonzini/qemu.
Thanks a lot for sharing this, we're going to have a look at it.
Cheers,
Samuel.