@@ -32,5 +32,62 @@ $ cd buildroot
3232$ make BR2_EXTERNAL=../coreos_buildroot menuconfig
3333```
3434This connects the two repos together and exposes all of the coreos_buildroot
35- options through the menu option "User-provided options --->"
35+ options through the menu option ` "User-provided options --->" `
3636
37+ ## Using CoreOS Buildroot
38+
39+ ### Creating a new ` defconfig `
40+
41+ defconfigs are default sets of options which are used to populate a ` .config `
42+ file inside of buildroot. Using a defconfig file one is able to persist a list
43+ of configuration options beyond the life cycle of a single checkout of
44+ buildroot. This is to say that the defconfig removes things not essential to
45+ the generation of the user defined filesystem so that as various default options
46+ change over time, the user is able to cleanly integrate them.
47+
48+ To create a new defconfig file the user will configure the container and then
49+ perform a save operation which will strip out the extraneous configuration
50+ options. The starting process for this can begin in two ways: Start from an
51+ empty config (e.g. ` make menuconfig ` from within a clean repository checkout) or
52+ start from another defconfig, mutate it, and save the changes. In the first
53+ case it is just as simple as removing an existing ` .config ` file from the
54+ upstream buildroot checkout and running ` make menuconfig ` .
55+
56+ If one wishes to start from an existing defconfig, they will identify the
57+ configuration they wish to start from in either
58+ [ buildroot/configs] ( https://github.com/buildroot/buildroot/tree/master/configs )
59+ or from
60+ [ coreos_buildroot/configs] ( https://github.com/brianredbeard/coreos_buildroot/tree/master/configs ) .
61+
62+ Once a starting defconfig has been chosen, one uses the name of that defconfig
63+ as as argument to ` make ` , e.g. ` make corebox_defconfig ` and then makes relevant
64+ changes using ` make menuconfig ` .
65+
66+ After any desired changes have been made through ` make menuconfig ` , the command
67+ ` make savedefconfig ` is used. If one wishes to provide a filename for the saved
68+ artifact, it can be supplied with the variable ` BR2_DEFCONFIG ` , e.g. `make
69+ savedefconfig BR2_DEFCONFIG=../coreos_buildroot/configs/example_defconfig`. Any
70+ defconfigs should always end with the string ` _defconfig ` .
71+
72+ ### Things to remember when defining options for a generated artifact
73+
74+ In the process of building a container filesystem there are a number of things
75+ that you will not need as compared to a full Linux distro. Some examples are an
76+ init system (e.g. sysVinit or systemd) or a kernel. At the same time many users
77+ will realize that they do not need
78+ [ locales] ( http://www.gnu.org/software/libc/manual/html_node/Locales.html ) beyond
79+ "` C ` " or "` POSIX ` ".
80+
81+ What some users may not understand is that even when * not* building a kernel,
82+ the _ kernel headers_ will still be needed to establish an [ application binary
83+ interface] ( https://en.wikipedia.org/wiki/Linux_kernel_interfaces#Linux_ABI )
84+ contract for program execution. As a part of this contract one must always use
85+ a _ lower_ version of the kernel headers than the kernel on the desired system.
86+ This means that 3.4.3 kernel headers can be used with a 3.10.0 or a 4.4.5
87+ kernel, but not a 2.6.32 kernel. This becomes important because a user needs to
88+ decide what is an appropriate level of kernel headers to use for a desired
89+ platform. This means that should a user choose to use the "latest and greatest"
90+ version of the kernel headers it _ may_ work on a CoreOS alpha instance but would
91+ not run on a CoreOS stable nor a Red Hat Enterprise Linux host. In general,
92+ sticking to using 3.4.x kernel headers is a safe bet which provides a broad
93+ level of compatibility across kernel versions.
0 commit comments