From: Stefan Hengelein <ilendir@gmail.com>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction
Date: Thu, 14 Aug 2014 21:57:16 +0200 [thread overview]
Message-ID: <53ED149C.8030104@gmail.com> (raw)
In-Reply-To: <20140813180743.GB16662@roeck-us.net>
> "My scope, which is more focused on testing, is a bit different.
> Major problem I see is that many architecture maintainers don't seem
to care
> about "make allmodconfig" and/or "make allyesconfig", meaning there is no
> simple means to at least compile-test all code that _can_ be enabled for
> a given architecture. And don't even mention "make randconfig".
We [1] develop a tool (called 'vampyr'), which ships the desired
functionality of compile-testing source code.
The Vampyr inspects the CPP blocks of a given source file and creates
one or more configurations to maximize the code coverage. Once the
configurations are generated, Vampyr triggers the compilation process on
the given source files and reports compiler issues (i.e., warnings and
errors) to the user.
Furthermore, Vampyr offers an interface to specify compilers to allow
cross-compilation for other architectures such as ARM or MIPS. Note that
Vampyr expands the configurations with "KCONFIG_ALLCONFIG=file.config?
make allyesconfig", where 'allyesconfig' can be altered with the Vampyr
interface (e.g. to 'allnoconfig'). On the current Linux HEAD the tool
reaches a code coverage of 83 percent, whereas a plain "make
allyesconfig" covers 64 percent of the source code [5]. You can find
further information about the tool in a recently published paper on
USENIX'14 [2].
> Furthermore, allnoconfig disables CONFIG_MMU on architectures that
support
> nommu, which is less interesting, and thus need a KCONFIG_ALLCONFIG=
> trick (I'd love to have just "make CONFIG_MMU=y allnoconfig" instead).
If you want to forcefully set specific features to be always off or
always on, you can specify an additional whitelist and/or a blacklist.
For more information check out [3] or download the tarball containing
the tool here [4].
If you have questions or desire more information about the tool, feel
free to contact us.
Best Regards,
Andreas Ruprecht, Valentin Rothberg, Stefan Hengelein
[1] https://www4.cs.fau.de/Research/CADOS/
[2] https://www4.cs.fau.de/Publications/2014/tartler_14_usenix.pdf
[3] http://vamos.informatik.uni-erlangen.de/trac/undertaker/wiki
[4] http://vamos.informatik.uni-erlangen.de/files/undertaker-1.5.tar.xz
[5]
https://vamos.informatik.uni-erlangen.de/jenkins/job/vamos-linux-expansion-stats-weekly/103/artifact/expansion-bigtable.pdf
user: public pw: i4guest
PS: Another interesting tool (unfortunately it's still in development)
may be 'undertaker-checkpatch', which can be used to check Git commits
for #ifdef-related bugs. We are planning to enhance this tool to run a
Vampyr compile-test analysis on affected files.
next prev parent reply other threads:[~2014-08-14 19:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 17:29 Bird, Tim
2014-08-13 18:07 ` Guenter Roeck
2014-08-13 19:53 ` Geert Uytterhoeven
2014-08-13 22:45 ` Guenter Roeck
2014-08-14 0:14 ` Mark Brown
2014-08-14 0:38 ` Guenter Roeck
2014-08-14 15:33 ` Mark Brown
2014-08-14 7:49 ` Geert Uytterhoeven
2014-08-14 16:39 ` Mark Brown
2014-08-14 7:40 ` Geert Uytterhoeven
2014-08-14 8:50 ` Guenter Roeck
2014-08-14 9:02 ` Geert Uytterhoeven
2014-08-15 11:04 ` Guenter Roeck
2014-08-14 19:57 ` Stefan Hengelein [this message]
2014-08-13 19:19 ` josh
2014-08-14 16:30 ` Tim Bird
2014-08-14 17:17 ` Josh Triplett
2014-08-14 16:03 ` Christoph Lameter
2014-08-14 18:54 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53ED149C.8030104@gmail.com \
--to=ilendir@gmail.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=stefan.hengelein@fau.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox