1. 04 Jul, 2016 1 commit
  2. 15 Jun, 2016 1 commit
  3. 14 Jun, 2016 1 commit
  4. 11 Jun, 2016 1 commit
  5. 10 Jun, 2016 1 commit
  6. 01 Jun, 2016 1 commit
  7. 16 May, 2016 1 commit
  8. 15 May, 2016 1 commit
  9. 13 May, 2016 1 commit
    • Michael Munday's avatar
      unix: add s390x support · 33267e03
      Michael Munday authored
      This commit adds linux/s390x support to the unix package. It is
      based on the changes made to the syscall package in
      https://golang.org/cl/20961/. It also adds mkpost.go which is
      used to cleanup the API generated by cgo -godefs.
      
      The biggest departure that is made with the syscall package is
      the use of the -fsigned-char flag to force signed chars. We
      couldn't do this in the syscall package because of the need to
      maintain compatibility with the gccgo implementation of the syscall
      package (gccgo has supported s390x for a longer time than the Go
      toolchain). The unix package does not have this constraint.
      
      Using the -fsigned-char flag makes the API look more like the one
      generated on amd64 and arm64 and also more consistent with itself
      (the syscall package represents chars using both int8 and uint8
      types, the sys package will only ever use int8). Unfortunately it
      also means that applications transitioning from the syscall package
      to the unix package will see a different API on s390x which might
      be confusing. I think the tradeoff is worth it though.
      
      Change-Id: I40b90c18ed787e74ba7a2ebd004bd6bd1ba6279a
      Reviewed-on: https://go-review.googlesource.com/23045Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      33267e03
  10. 12 May, 2016 1 commit
  11. 11 May, 2016 1 commit
  12. 29 Apr, 2016 1 commit
  13. 27 Apr, 2016 1 commit
  14. 15 Apr, 2016 1 commit
    • Riku Voipio's avatar
      unix: fix Pause on linux-arm64 · f64b50fb
      Riku Voipio authored
      Pause is a legacy syscall not available on linux-arm64. Use ppoll with
      all args as 0 to emulate - this is the way musl libc does Pause when the
      pause syscall isn't available.
      
      With the changes in syscall_linux* and regenerating zsyscall_linux*,
      this calling Pause on linux-arm64 works and returns EINTR as expected.
      
      Change-Id: I88236290313f18c742d826e759e86ff260a8b383
      Reviewed-on: https://go-review.googlesource.com/22014Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      f64b50fb
  15. 13 Apr, 2016 1 commit
  16. 09 Apr, 2016 1 commit
  17. 08 Apr, 2016 3 commits
  18. 06 Apr, 2016 1 commit
  19. 05 Apr, 2016 1 commit
  20. 02 Apr, 2016 2 commits
  21. 25 Mar, 2016 1 commit
  22. 22 Mar, 2016 2 commits
  23. 15 Mar, 2016 1 commit
  24. 03 Mar, 2016 1 commit
  25. 29 Feb, 2016 1 commit
    • Benoit Sigoure's avatar
      x/sys/unix: Add support for the setns system call. · 54535356
      Benoit Sigoure authored
      This system call is used to reassociate the current thread with a Linux
      namespace (e.g. a network namespace or a mount namespace).  This system
      call is key to interacting with the primitives enabling Linux containers.
      The users of this system call will most likely want to wrap their calls
      with a pair of LockOSThread / UnlockOSThread calls.  Here is an example
      that is a reasonably close approximation of the `ns_exec' program given
      as an example in `man 2 setns':
      
      	package main
      
      	import (
      		"log"
      		"os"
      		"os/exec"
      		"runtime"
      
      		"golang.org/x/sys/unix"
      	)
      
      	func main() {
      		if len(os.Args) < 3 {
      			log.Fatalf("%s /proc/PID/ns/FILE cmd args...", os.Args[0])
      		}
      		fd, err := unix.Open(os.Args[1], unix.O_RDONLY, 0)
      		if err != nil {
      			log.Fatalf("open: %s", err)
      		}
      		runtime.LockOSThread()
      		defer runtime.UnlockOSThread()
      		if err = unix.Setns(fd, 0); err != nil {
      			log.Fatalf("setns: %s", err)
      		}
      		cmd := exec.Command(os.Args[2], os.Args[3:]...)
      		cmd.Stdin = os.Stdin
      		cmd.Stdout = os.Stdout
      		cmd.Stderr = os.Stderr
      		err = cmd.Run()
      		if err != nil {
      			log.Fatalf("exec: %s", err)
      		}
      	}
      
      Fixes golang/go#5968.
      
      Change-Id: I78dc54667cfaef4f9e99a08d48f6e423686f1b22
      Reviewed-on: https://go-review.googlesource.com/20054Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      54535356
  26. 28 Feb, 2016 2 commits
  27. 22 Feb, 2016 1 commit
  28. 04 Feb, 2016 1 commit
  29. 27 Jan, 2016 1 commit
  30. 21 Jan, 2016 1 commit
  31. 13 Jan, 2016 1 commit
  32. 11 Dec, 2015 1 commit
  33. 24 Nov, 2015 1 commit
    • Nick Patavalis's avatar
      unix: Fix Termios type definition · 2bacc619
      Nick Patavalis authored
      - types_linux.go: Use the kernel-defined termios structure, *not* the
        LIBC-defined one. The LIBC termios structure cannot be safely used
        to do tty-related ioctls on all architectures (e.g. ppc64,
        ppc64le). The kernel termios structure, and the associated
        macros/constants, are defined in: "asm/termbits.h" which is included
        by "linux/termios.h". The LIBC termios structure is defined in
        "bits/termios.h" which is included by "termios.h". These structures
        are *not* the same.
      
        For systems that have both "struct termios" and "struct termios2"
        use the latter to define the Termios type. This is ok, since the
        "struct termios2" memory layout is compatible with "struct termios"
        (with a couple of fields added at the end). This way, type Termios
        can be used with both: the "old-style" TCSETS[FW], TCGETS ioctls,
        *and* with the new TCSETS[FW]2, TCGETS2 ioctls. The new ioctls allow
        configuring arbitrary baudrates.
      
        The new Termios definitions (kernel-compatible) have the same fields
        as the old ones (LIBC-derived) so there should be no user-code
        compatibility issues.
      
      Change-Id: I3c1484c60f45b28e13404765c01616c33063afd5
      Reviewed-on: https://go-review.googlesource.com/17185Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      2bacc619
  34. 23 Nov, 2015 1 commit
  35. 29 Oct, 2015 1 commit