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.
