Features/Kconfig (GSoC 2013): Difference between revisions
Akoskovacs (talk | contribs) |
No edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
'''UPDATE:''' The kconfig language was integrated in QEMU 4.0. | |||
== Summary == | == Summary == | ||
| Line 14: | Line 16: | ||
== Implementation == | == Implementation == | ||
=== Main topics === | === Main topics === | ||
# Importing [http://ymorin.is-a-geek.org/projects/kconfig-frontends kconfig-frontends] to Qemu (at scripts/kconfig) | # Importing [http://ymorin.is-a-geek.org/projects/kconfig-frontends kconfig-frontends] to Qemu (at ''scripts/kconfig'') | ||
# New syntactical structures in the Kconfig files (with writing the actual Kconfig files) | # New syntactical structures in the Kconfig files (with writing the actual Kconfig files) | ||
# Integrating kconfig to the existing build infrastructure | # Integrating kconfig to the existing build infrastructure | ||
=== Progress === | === Progress === | ||
At the time, the first and the second topic is in progress. This means, that the kconfig-frontends can be built from the top-level directory (with 'make menuconfig/xconfig/gconfig/...') and has a new syntactical structure. | At the time, the first and the second topic is in progress. This means, that the kconfig-frontends can be built from the top-level directory (with 'make menuconfig/xconfig/gconfig/...') and has a new syntactical structure. | ||
This will enable the user to manage all targets from one root Kconfig file. The current syntax consist a 'symbol' token and the actual symbol itself, which can be written this way: | |||
This will enable the user to manage all targets from one root Kconfig file. The current syntax consist a 'symbol' token and the actual symbol itself, which can be written in this way: | |||
<code> | <code> | ||
| Line 30: | Line 33: | ||
However, this is not a fixed syntax and there could be other ways. | However, this is not a fixed syntax and there could be other ways. | ||
Another challenge, is to get the currently supported devices and boards for each target and to transform them to usable Kconfig files. Qemu has already have a feature, which can dump the devices at the runtime. This tree can be gathered with the ''info qtree'' command in the Qemu monitor. The board list can be gathered in a similar way, with ''-M ?'' command line options. If everything works fine, we just need to get name of the C files, where these devices implemented. | |||
However some targets are not able to provide the device tree without a valid image. Therefore, a better way could be a hack in the Qemu's source code. A call to the printf() in the right place can make miracles. This means, we can get the full lists of devices and boards with a call in the ''target_register_internal()'' and the ''qemu_register_machine()''. Some macros with these names can also make this hack more effective, so we can get list with the associated C files (using the ''__FILE__''). | |||
== Code repository == | |||
Current code repository is available at [https://github.com/akoskovacs/qemu/tree/kconfig github]. ''git clone git://github.com/akoskovacs/qemu.git'' | |||
[[Category:Obsolete feature pages]] | |||
Latest revision as of 15:35, 22 May 2019
UPDATE: The kconfig language was integrated in QEMU 4.0.
Summary
The aim of this Google Summer of Code 2013 project is to bring the Linux kernel's Kconfig facility to Qemu, making it much easier to configure at build-time.
Owner
- Name: Ákos Kovács
- Email: akoskovacs@gmx.com
Implementation
Main topics
- Importing kconfig-frontends to Qemu (at scripts/kconfig)
- New syntactical structures in the Kconfig files (with writing the actual Kconfig files)
- Integrating kconfig to the existing build infrastructure
Progress
At the time, the first and the second topic is in progress. This means, that the kconfig-frontends can be built from the top-level directory (with 'make menuconfig/xconfig/gconfig/...') and has a new syntactical structure.
This will enable the user to manage all targets from one root Kconfig file. The current syntax consist a 'symbol' token and the actual symbol itself, which can be written in this way:
config TEST
prompt "A foo-bar feature"
symbol TARGET_FOO
default n
However, this is not a fixed syntax and there could be other ways.
Another challenge, is to get the currently supported devices and boards for each target and to transform them to usable Kconfig files. Qemu has already have a feature, which can dump the devices at the runtime. This tree can be gathered with the info qtree command in the Qemu monitor. The board list can be gathered in a similar way, with -M ? command line options. If everything works fine, we just need to get name of the C files, where these devices implemented.
However some targets are not able to provide the device tree without a valid image. Therefore, a better way could be a hack in the Qemu's source code. A call to the printf() in the right place can make miracles. This means, we can get the full lists of devices and boards with a call in the target_register_internal() and the qemu_register_machine(). Some macros with these names can also make this hack more effective, so we can get list with the associated C files (using the __FILE__).
Code repository
Current code repository is available at github. git clone git://github.com/akoskovacs/qemu.git