Re: [Qemu-devel] QEMU and Kconfig

[Samuel Ortiz]

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.