Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini]

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)

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.

>> - Did this GSoC project ever started?

Yes and it was also finished, but it was not merged.

>  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. :)

Paolo

> Whether Kconfig would still make sense for QEMU - I don't know. A good
> way for configuring the CONFIG_xxx switches in the default-configs
> folder would be very appealing, but I think we still need something
> equivalent to the "configure" script that also detects the libraries
> that are available on the host system. Can Kconfig also provide such a
> detection mechanism?
> 
>   Thomas
>