public inbox for gentoo-soc@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-soc] kernelconfig - final report
@ 2016-08-22 20:01 André Erdmann
  0 siblings, 0 replies; only message in thread
From: André Erdmann @ 2016-08-22 20:01 UTC (permalink / raw
  To: gentoo-soc; +Cc: Rafael Martins, Denis Dupeyron

Hi everyone,


== Brief summary of this project ==

kernelconfig is about generating kernel configuration files,
using various sources such as curated defconfigs, detected hardware,
installed packages and user input.

The project's code can be found at [0].


== Current state of this project and future directions ==

GSoC 2016 is almost over,
so it's time to summarize what has been achieved this summer.

kernelconfig is a tool for generating kernel configurations.
It started as a rewrite of the original project [1],
and has been extended considerably since then.
It is written mostly in Python, plus some C, make and sh.

The functionality can be divided into two larger parts,
"configuration sources" and "config generation".

Config generation takes a .config file as input,
applies user-requested modifications and creates the output .config file.

The kernel configuration is modified via a micro-language
with support for conditional expressions.

Modification requests can be direct - enable a specific option,
or indirect - hardware detection, package management integration.
For a given config option, kernelconfig knows whether it exists and also
additional information such as its type, and is able to find out which other
options need to be set as well so that the modification request is effective
and does not disappear during the next "make oldconfig" run. For example,
users can set "CONFIG_CMDLINE" without having to worry about its dependency,
"CONFIG_CMDLINE_BOOL".

Hardware detection scans /sys for drivers and modalias information
and enables config options accordingly.
While driver-based detection is always available, it works for known
devices only.
In contrast, modalias-based detection can handle unknown devices,
but relies on "modalias information source" files, which have to be created
in a lengthy "make allmodconfig && make modules" run. kernelconfig offers
a helper script for that purpose, and the created files are shareable.
The scanning itself can be offloaded to the "hwcollect" shell script, which
has minimal dependencies and can be run on a different machine, e.g. a
live system.

Package management integration reuses the CONFIG_CHECK mechanism from
linux-info.eclass. It queries portage for a list of installed packages
and either uses their build-time value or re-runs the relevant ebuild phases
in a temporary overlay to get more correct results, based on the version of
the kernel sources for which a .config is being processed, in particular.

"Configuration sources" are responsible for providing the input .config file.
A configuration source can be a .config file, a make target,
a script or command, or a Python module.
kernelconfig turns it into some sort of a mini-subprogram by adding an
argument parser, checking whether the target architecture is supported,
substituting tmpfile format variables in commands/scripts,
and providing a common runtime environment.
Python module configuration sources use an interface/api that offers
common functionality and better error reporting than the other types.

Currently, there are configuration sources for .config files
from CentOS, Debian, Fedora, Liquorix and Ubuntu.
The latter two have been adapted from the original project.

Extensive documentation is available at [2] (html: [3]) and covers usage,
installation, configuration, how config generation works and how to add
new configuration sources.
For those familiar with the original project, there is also an estimation as
to how compatible the config files and scripts are [4]. In short, mostly.

Some features have been implemented differently from what I initially had in
mind, but, overall, I've accomplished most objectives of my proposal.
One feature has been dropped, genkernel integration, in favor of having more
time for doc-writing. I consider it as a possible future extension.

Speaking of the future, I'm willing to maintain the project, fix and improve
things where necessary. I'm also open to feature suggestions ;-)

At last, I'd like to thank Rafael (rafaelmartins), my mentor, and guidance
and suggestions throughout the past months, and Denis (Calchan) for suggestions
and inviting me to participate this year.


[0] https://github.com/dywisor/kernelconfig
[1] https://github.com/Calchan/kernelconfig
[2] https://github.com/dywisor/kernelconfig/blob/master/doc/rst/userguide.rst
[3] https://htmlpreview.github.io/?https://raw.githubusercontent.com/dywisor/kernelconfig/master/doc/html/userguide.html
[4] https://github.com/dywisor/kernelconfig/blob/3041e678c1556b5bbc7e9590be088182f4713fdb/doc/rst/compatibility_rewrite_original.rst


Regards,
André E.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2016-08-22 20:01 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-22 20:01 [gentoo-soc] kernelconfig - final report André Erdmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox