Only subcommand is currently `create` which is a thin wrapper to create an iso
file in the format expected by `pkg/metadata`.
Currently very basic and just takes the content on the command line but could
be extended to read from a file etc.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
If a file is a simple string (as opposed to a map) then write it with the
default perms. This makes for slightly terser metadata when creating a simple
datafile.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
`ok` was not assigned when type casting to `map[string]interface{}` so the
subsequent check was testing a stale value.
Also, the error message upon failure had the wrong sense.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Pick up the new versin of the virtsock test package
Also remove the iso-ios output and adjust the choice of Linux kernels.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The new version has improvements to the Windows code as well
as initial support for the VMware/virtio based Hyper-V socket
interface.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Note these are only the ones using the `containerd` based `init` as
the `runc` ones are still using an old one.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In order to enable Hyper-V sockets, the CONFIG_HYPERV_VSOCKETS
option must be set. This is different to the older kernel patches.
In order for the Hyper-V socket code to compile, f3dd3f4797652c311df
("vmbus: introduce in-place packet iterator") needed cherry-picking.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@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>
