linux-kernel - Monster switch for small size (was Linux-tiny revival)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Sep 2007 10:10:50 -0700
From:	Tim Bird <tim.bird@...sony.com>
To:	Andy Whitcroft <apw@...dowen.org>
CC:	Michael Opdenacker <michael@...e-electrons.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	linux-tiny <Linux-tiny@...enic.com>,
	CE Linux Developers List <celinux-dev@...e.celinuxforum.org>
Subject: Monster switch for small size (was Linux-tiny revival)

Andy Whitcroft wrote:
> Knowing nothing about these options, from a test perspective it would
> be nice if we were able to simply enable "the lot" so we can do "normal"
> -mm runs and "tiny" -mm runs without any manual intervention?

I agree completely.

I have been thinking for a while about how to make a "monster switch"
(the kind they always seem to have in Frankenstein movies) that
switches a whole bunch of settings at once.  We currently have methods
in the kernel for:
 * default (or recommended) config for a particular platform
 * all yes - to build as much as possible
 * all no - to build as little as possible

The problem with "allno" is that it rarely produces a usable
kernel.

There are three possible approaches that I can think of:
 1) use a tool to start from default and turn off options
 to make a small (but still usable) config
   * I have a tool to do this now as part of my automated test
   I haven't published it, but I can if anyone's interested.
 2) use the kconfig dependency system to disable stuff automatically
 if someone chooses the "make_it_small" option.
 3) create defconfig_small files for the platforms that care about
 size

3) is easiest to implement at first.  It's trivial to make a new
defconfig, and we could easily come up with a convention for them.
However, they would be a pain to maintain (this would essentially
double the defconfig maintenance), and you'd have to convince
people that it's worth carrying these in the mainline tree.

I haven't looked at 2), so I'm not sure exactly what would be
involved.  I'm not sure if you can centralize all the dependency
information in the "make_it_small" option, or if you'd have
to spread it out to the related configs.  I'm not even sure which
arrangement of the info would be the easiest to maintain.  Would
it be best to have a single size-conscious person maintain the
dependencies, or better for config authors to maintain this info
in parallel?

Anyway, those are just some thoughts on the subject.
Feedback on an acceptable solution would be welcome.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/