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 >
