This is style information, even though it's about the spec and not
about the behavior covered by the spec. The Go-pointer rule is also
about more peripheral stuff though, and the README has a lot of stuff
in it, so it seems like a better fit after the move.
Signed-off-by: W. Trevor King <wking@tremily.us>
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
The general rule seems to be:
If Go's default value has the same semantics we'd use for an unset
value, don't bother with a pointer.
I'm not sure how well that squares with [1]:
We want a consistent way to identify unset settings.
But if the falsy values count as "unset", maybe the "null is a
consistent identifier for unset" approach was never really viable.
Qiang points out that pointers are required to opt-out of boolean
settings where both true and false would require action [2], so I've
worded the exception to only apply when the Go default for the type is
expicitly a no-op in the spec.
I'm also not sure if the new style extends to integers where zero has
the same semantics as unset values. It sounds like Michael was ok
with no pointers for those values [3], but OOMScoreAdj (where zero
clearly means "do nothing") got a pointer in #233 [4]. More clarity
on the threshold would be nice; in this commit I've laid out the logic
and not explicitly listed the types it applies to.
[1]: https://github.com/opencontainers/specs/pull/233#discussion_r47829711
[2]: https://github.com/opencontainers/specs/pull/317/files#r50932706
[3]: https://github.com/opencontainers/specs/pull/233#issuecomment-155250592
[4]: https://github.com/opencontainers/specs/pull/233/files#diff-34c30be66233f08b447fb608ea0e66bbR206
Signed-off-by: W. Trevor King <wking@tremily.us>
pandoc/LaTeX is not happy with this shady character.
```
! Package inputenc Error: Unicode char \u8:↔ not set up for use with
LaTeX.
```
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
So we have something to cite to avoid rehashing established decisions.
Provide some motivation and links to the backing discussion so folks
can re-open these if they have new information that wasn't covered in
the original decision.
Like the glossary (18734986, glossary: Provide a quick overview of
important terms, 2015-08-11, #107), I've used subsection titles for
each entry to get link anchors.
Signed-off-by: W. Trevor King <wking@tremily.us>
Vincent Batts
W. Trevor King
Michael Crosby