1 |
Hi everyone, |
2 |
|
3 |
|
4 |
== Brief summary of this project == |
5 |
|
6 |
kernelconfig is about generating kernel configuration files, |
7 |
using various sources such as curated defconfigs, detected hardware, |
8 |
installed packages and user input. |
9 |
|
10 |
The project's code can be found at [0]. |
11 |
|
12 |
|
13 |
== Current state of this project and future directions == |
14 |
|
15 |
GSoC 2016 is almost over, |
16 |
so it's time to summarize what has been achieved this summer. |
17 |
|
18 |
kernelconfig is a tool for generating kernel configurations. |
19 |
It started as a rewrite of the original project [1], |
20 |
and has been extended considerably since then. |
21 |
It is written mostly in Python, plus some C, make and sh. |
22 |
|
23 |
The functionality can be divided into two larger parts, |
24 |
"configuration sources" and "config generation". |
25 |
|
26 |
Config generation takes a .config file as input, |
27 |
applies user-requested modifications and creates the output .config file. |
28 |
|
29 |
The kernel configuration is modified via a micro-language |
30 |
with support for conditional expressions. |
31 |
|
32 |
Modification requests can be direct - enable a specific option, |
33 |
or indirect - hardware detection, package management integration. |
34 |
For a given config option, kernelconfig knows whether it exists and also |
35 |
additional information such as its type, and is able to find out which other |
36 |
options need to be set as well so that the modification request is effective |
37 |
and does not disappear during the next "make oldconfig" run. For example, |
38 |
users can set "CONFIG_CMDLINE" without having to worry about its dependency, |
39 |
"CONFIG_CMDLINE_BOOL". |
40 |
|
41 |
Hardware detection scans /sys for drivers and modalias information |
42 |
and enables config options accordingly. |
43 |
While driver-based detection is always available, it works for known |
44 |
devices only. |
45 |
In contrast, modalias-based detection can handle unknown devices, |
46 |
but relies on "modalias information source" files, which have to be created |
47 |
in a lengthy "make allmodconfig && make modules" run. kernelconfig offers |
48 |
a helper script for that purpose, and the created files are shareable. |
49 |
The scanning itself can be offloaded to the "hwcollect" shell script, which |
50 |
has minimal dependencies and can be run on a different machine, e.g. a |
51 |
live system. |
52 |
|
53 |
Package management integration reuses the CONFIG_CHECK mechanism from |
54 |
linux-info.eclass. It queries portage for a list of installed packages |
55 |
and either uses their build-time value or re-runs the relevant ebuild phases |
56 |
in a temporary overlay to get more correct results, based on the version of |
57 |
the kernel sources for which a .config is being processed, in particular. |
58 |
|
59 |
"Configuration sources" are responsible for providing the input .config file. |
60 |
A configuration source can be a .config file, a make target, |
61 |
a script or command, or a Python module. |
62 |
kernelconfig turns it into some sort of a mini-subprogram by adding an |
63 |
argument parser, checking whether the target architecture is supported, |
64 |
substituting tmpfile format variables in commands/scripts, |
65 |
and providing a common runtime environment. |
66 |
Python module configuration sources use an interface/api that offers |
67 |
common functionality and better error reporting than the other types. |
68 |
|
69 |
Currently, there are configuration sources for .config files |
70 |
from CentOS, Debian, Fedora, Liquorix and Ubuntu. |
71 |
The latter two have been adapted from the original project. |
72 |
|
73 |
Extensive documentation is available at [2] (html: [3]) and covers usage, |
74 |
installation, configuration, how config generation works and how to add |
75 |
new configuration sources. |
76 |
For those familiar with the original project, there is also an estimation as |
77 |
to how compatible the config files and scripts are [4]. In short, mostly. |
78 |
|
79 |
Some features have been implemented differently from what I initially had in |
80 |
mind, but, overall, I've accomplished most objectives of my proposal. |
81 |
One feature has been dropped, genkernel integration, in favor of having more |
82 |
time for doc-writing. I consider it as a possible future extension. |
83 |
|
84 |
Speaking of the future, I'm willing to maintain the project, fix and improve |
85 |
things where necessary. I'm also open to feature suggestions ;-) |
86 |
|
87 |
At last, I'd like to thank Rafael (rafaelmartins), my mentor, and guidance |
88 |
and suggestions throughout the past months, and Denis (Calchan) for suggestions |
89 |
and inviting me to participate this year. |
90 |
|
91 |
|
92 |
[0] https://github.com/dywisor/kernelconfig |
93 |
[1] https://github.com/Calchan/kernelconfig |
94 |
[2] https://github.com/dywisor/kernelconfig/blob/master/doc/rst/userguide.rst |
95 |
[3] https://htmlpreview.github.io/?https://raw.githubusercontent.com/dywisor/kernelconfig/master/doc/html/userguide.html |
96 |
[4] https://github.com/dywisor/kernelconfig/blob/3041e678c1556b5bbc7e9590be088182f4713fdb/doc/rst/compatibility_rewrite_original.rst |
97 |
|
98 |
|
99 |
Regards, |
100 |
André E. |