Instead of figuring out which config files to use inside of makeconfig.sh,
let's figure that out in the Dockerfile and pass them into the script.
Signed-off-by: Tycho Andersen <tycho@docker.com>
Instead of having a special case sed script, we can just put this in the
.debug config file, and have a special case when it's being checked.
Signed-off-by: Tycho Andersen <tycho@docker.com>
Let's use the kernel machine architecture for this value.
Also remove a broken check. The "arch" binary on OSX outputs different
stuff than on linux. Since we don't need this check anyway (the variable
is mostly to demonstrate how cross platform stuff would work, not to
actually do it yet), let's just remove the check.
Signed-off-by: Tycho Andersen <tycho@docker.com>
The kernel configs themselves are stored as diffs of what we want vs. each
version's defconfig.
Thus, things like e.g. CONFIG_DEVKMEM drop out after it was made
non-default. The implication of this is (I hope) that as upstream adopts
security features, our delta can shrink (or more realistically, only
include the next-next gen features).
Signed-off-by: Tycho Andersen <tycho@docker.com>
This is the script I used with [1] to generate the config diffs and
separate out the arch specific bits. Included mostly just so people can
play around with it if they want to generate their own diffs.
[1]: https://github.com/ulfalizer/Kconfiglib
Signed-off-by: Tycho Andersen <tycho@docker.com>
In particular, let's start with a defconfig and edit it, rather than try to
generate the config entirely from our own diff.
Signed-off-by: Tycho Andersen <tycho@docker.com>
...and add straw man implementations of kernel_config.base and
kernel_config.x86 as examples.
First, splitting the build: to avoid duplication, we split the build into
three parts: a "source" stage, a "config" stage, and a "build" stage. The
"source" stage allows us to use a cached image, so we don't have to
re-download the kernel source every time. The "config" step applies our
patches and generates (and checks) the kernel config. I've left this as a
separate step for now so that we can build just an image with a config in
it, without having to ^C the build. However there's no real reason it needs
to be a separate step, assuming that this kernel config design is
acceptable. The third step is the actual kernel build.
Then there is kernel config management: the bulk of it occurs in
makeconfig.sh, with the idea being that we can specify base, arch, and
version specific config options as necessary.
The config files themselves are lists of options (both positive and
negative). We include the negative options, because we want to explicitly
turn off things that are on in the default config (e.g. CONFIG_USELIB), and
it seems cleaner to do things this way then to have some sort of negative
options list.
The options files are sorted with the default behavior of the "sort"
command, which ignores comment lines, meaning that negative options and
positive options are inline with each other. I don't have a strong opinion
on whether or not to group all negative options, or whether this default
behavior makes sense, so I just left it.
Finally, obviously the .base and .x86 files are incomplete. I mostly
selected a few options with interesting dependencies or special issues
(CONFIG_PANIC_ON_OOPS) with how we manage things, so as to demo how
everything would work. It's not really clear to me that there's a good way
to generate e.g. kernel_config.base, without a lot of painstaking work
(which I'm happy to do if we agree this is a good approach).
Signed-off-by: Tycho Andersen <tycho@docker.com>
This is just a direct import of the current kernel/ directory, with a
slight splitting up of the dockerfiles to build a kernel-source and kernel
image.
Signed-off-by: Tycho Andersen <tycho@docker.com>
