gvisor - Container Runtime Sandbox

Age	Commit message (Collapse)	Author
2019-05-03	gvisor: run bazel in a docker container	Andrei Vagin
	bazel has a lot of dependencies and users don't want to install them just to build gvisor. These changes allows to run bazel in a docker container. A bazel cache is on the local file system (~/.cache/bazel), so incremental builds should be fast event after recreating a bazel container. Here is an example how to build runsc: make BAZEL_OPTIONS="build runsc:runsc" bazel Change-Id: I8c0a6d0c30e835892377fb6dd5f4af7a0052d12a PiperOrigin-RevId: 246570877
2019-04-29	Change copyright notice to "The gVisor Authors"	Michael Pratt
	Based on the guidelines at https://opensource.google.com/docs/releasing/authors/. 1. $ rg -l "Google LLC" \| xargs sed -i 's/Google LLC.*/The gVisor Authors./' 2. Manual fixup of "Google Inc" references. 3. Add AUTHORS file. Authors may request to be added to this file. 4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS. Fixes #209 PiperOrigin-RevId: 245823212 Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
2019-04-03	Fix index out of bounds in tty implementation.	Kevin Krakauer
	The previous implementation revolved around runes instead of bytes, which caused weird behavior when converting between the two. For example, peekRune would read the byte 0xff from a buffer, convert it to a rune, then return it. As rune is an alias of int32, 0xff was 0-padded to int32(255), which is the hex code point for ?. However, peekRune also returned the length of the byte (1). When calling utf8.EncodeRune, we only allocated 1 byte, but tried the write the 2-byte character ?. tl;dr: I apparently didn't understand runes when I wrote this. PiperOrigin-RevId: 241789081 Change-Id: I14c788af4d9754973137801500ef6af7ab8a8727
2018-12-10	Open source system call tests.	Brian Geffon
	PiperOrigin-RevId: 224886231 Change-Id: I0fccb4d994601739d8b16b1d4e6b31f40297fb22