1
0
mirror of https://github.com/golang/go synced 2024-10-05 23:11:21 -06:00
go/src/pkg/syscall/syscall_bsd.go

623 lines
16 KiB
Go
Raw Normal View History

// Copyright 2009 The Go Authors. All rights reserved.
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// +build darwin freebsd netbsd openbsd
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// BSD system call wrappers shared by *BSD based systems
// including OS X (Darwin) and FreeBSD. Like the other
// syscall_*.go files it is compiled as Go code but also
// used as input to mksyscall which parses the //sys
// lines and generates system call stubs.
package syscall
import (
"runtime"
"unsafe"
)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
/*
* Pseudo-system calls
*/
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// The const provides a compile-time constant so clients
// can adjust to whether there is a working Getwd and avoid
// even linking this function into the binary. See ../os/getwd.go.
const ImplementsGetwd = false
func Getwd() (string, error) { return "", ENOTSUP }
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
/*
* Wrapped
*/
//sysnb getgroups(ngid int, gid *_Gid_t) (n int, err error)
//sysnb setgroups(ngid int, gid *_Gid_t) (err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Getgroups() (gids []int, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
n, err := getgroups(0, nil)
if err != nil {
return nil, err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
if n == 0 {
return nil, nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
// Sanity check group count. Max is 16 on BSD.
if n < 0 || n > 1000 {
return nil, EINVAL
}
a := make([]_Gid_t, n)
n, err = getgroups(n, &a[0])
if err != nil {
return nil, err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
gids = make([]int, n)
for i, v := range a[0:n] {
gids[i] = int(v)
}
return
}
func Setgroups(gids []int) (err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if len(gids) == 0 {
return setgroups(0, nil)
}
a := make([]_Gid_t, len(gids))
for i, v := range gids {
a[i] = _Gid_t(v)
}
return setgroups(len(a), &a[0])
}
func ReadDirent(fd int, buf []byte) (n int, err error) {
// Final argument is (basep *uintptr) and the syscall doesn't take nil.
// TODO(rsc): Can we use a single global basep for all calls?
return Getdirentries(fd, buf, new(uintptr))
}
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// Wait status is 7 bits at bottom, either 0 (exited),
// 0x7F (stopped), or a signal number that caused an exit.
// The 0x80 bit is whether there was a core dump.
// An extra number (exit code, signal causing a stop)
// is in the high bits.
type WaitStatus uint32
const (
mask = 0x7F
core = 0x80
shift = 8
exited = 0
stopped = 0x7F
)
func (w WaitStatus) Exited() bool { return w&mask == exited }
func (w WaitStatus) ExitStatus() int {
if w&mask != exited {
return -1
}
return int(w >> shift)
}
func (w WaitStatus) Signaled() bool { return w&mask != stopped && w&mask != 0 }
func (w WaitStatus) Signal() Signal {
sig := Signal(w & mask)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if sig == stopped || sig == 0 {
return -1
}
return sig
}
func (w WaitStatus) CoreDump() bool { return w.Signaled() && w&core != 0 }
func (w WaitStatus) Stopped() bool { return w&mask == stopped && Signal(w>>shift) != SIGSTOP }
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func (w WaitStatus) Continued() bool { return w&mask == stopped && Signal(w>>shift) == SIGSTOP }
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func (w WaitStatus) StopSignal() Signal {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if !w.Stopped() {
return -1
}
return Signal(w>>shift) & 0xFF
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
func (w WaitStatus) TrapCause() int { return -1 }
//sys wait4(pid int, wstatus *_C_int, options int, rusage *Rusage) (wpid int, err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Wait4(pid int, wstatus *WaitStatus, options int, rusage *Rusage) (wpid int, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var status _C_int
wpid, err = wait4(pid, &status, options, rusage)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if wstatus != nil {
*wstatus = WaitStatus(status)
}
return
}
//sys accept(s int, rsa *RawSockaddrAny, addrlen *_Socklen) (fd int, err error)
//sys bind(s int, addr uintptr, addrlen _Socklen) (err error)
//sys connect(s int, addr uintptr, addrlen _Socklen) (err error)
//sysnb socket(domain int, typ int, proto int) (fd int, err error)
//sys getsockopt(s int, level int, name int, val uintptr, vallen *_Socklen) (err error)
//sys setsockopt(s int, level int, name int, val uintptr, vallen uintptr) (err error)
//sysnb getpeername(fd int, rsa *RawSockaddrAny, addrlen *_Socklen) (err error)
//sysnb getsockname(fd int, rsa *RawSockaddrAny, addrlen *_Socklen) (err error)
//sys Shutdown(s int, how int) (err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func (sa *SockaddrInet4) sockaddr() (uintptr, _Socklen, error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if sa.Port < 0 || sa.Port > 0xFFFF {
return 0, 0, EINVAL
}
sa.raw.Len = SizeofSockaddrInet4
sa.raw.Family = AF_INET
p := (*[2]byte)(unsafe.Pointer(&sa.raw.Port))
p[0] = byte(sa.Port >> 8)
p[1] = byte(sa.Port)
for i := 0; i < len(sa.Addr); i++ {
sa.raw.Addr[i] = sa.Addr[i]
}
return uintptr(unsafe.Pointer(&sa.raw)), _Socklen(sa.raw.Len), nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
func (sa *SockaddrInet6) sockaddr() (uintptr, _Socklen, error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
if sa.Port < 0 || sa.Port > 0xFFFF {
return 0, 0, EINVAL
}
sa.raw.Len = SizeofSockaddrInet6
sa.raw.Family = AF_INET6
p := (*[2]byte)(unsafe.Pointer(&sa.raw.Port))
p[0] = byte(sa.Port >> 8)
p[1] = byte(sa.Port)
sa.raw.Scope_id = sa.ZoneId
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
for i := 0; i < len(sa.Addr); i++ {
sa.raw.Addr[i] = sa.Addr[i]
}
return uintptr(unsafe.Pointer(&sa.raw)), _Socklen(sa.raw.Len), nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
func (sa *SockaddrUnix) sockaddr() (uintptr, _Socklen, error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
name := sa.Name
n := len(name)
if n >= len(sa.raw.Path) || n == 0 {
return 0, 0, EINVAL
}
sa.raw.Len = byte(3 + n) // 2 for Family, Len; 1 for NUL
sa.raw.Family = AF_UNIX
for i := 0; i < n; i++ {
sa.raw.Path[i] = int8(name[i])
}
return uintptr(unsafe.Pointer(&sa.raw)), _Socklen(sa.raw.Len), nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
func (sa *SockaddrDatalink) sockaddr() (uintptr, _Socklen, error) {
if sa.Index == 0 {
return 0, 0, EINVAL
}
sa.raw.Len = sa.Len
sa.raw.Family = AF_LINK
sa.raw.Index = sa.Index
sa.raw.Type = sa.Type
sa.raw.Nlen = sa.Nlen
sa.raw.Alen = sa.Alen
sa.raw.Slen = sa.Slen
for i := 0; i < len(sa.raw.Data); i++ {
sa.raw.Data[i] = sa.Data[i]
}
return uintptr(unsafe.Pointer(&sa.raw)), SizeofSockaddrDatalink, nil
}
func anyToSockaddr(rsa *RawSockaddrAny) (Sockaddr, error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
switch rsa.Addr.Family {
case AF_LINK:
pp := (*RawSockaddrDatalink)(unsafe.Pointer(rsa))
sa := new(SockaddrDatalink)
sa.Len = pp.Len
sa.Family = pp.Family
sa.Index = pp.Index
sa.Type = pp.Type
sa.Nlen = pp.Nlen
sa.Alen = pp.Alen
sa.Slen = pp.Slen
for i := 0; i < len(sa.Data); i++ {
sa.Data[i] = pp.Data[i]
}
return sa, nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
case AF_UNIX:
pp := (*RawSockaddrUnix)(unsafe.Pointer(rsa))
if pp.Len < 3 || pp.Len > SizeofSockaddrUnix {
return nil, EINVAL
}
sa := new(SockaddrUnix)
n := int(pp.Len) - 3 // subtract leading Family, Len, terminating NUL
for i := 0; i < n; i++ {
if pp.Path[i] == 0 {
// found early NUL; assume Len is overestimating
n = i
break
}
}
bytes := (*[10000]byte)(unsafe.Pointer(&pp.Path[0]))[0:n]
sa.Name = string(bytes)
return sa, nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
case AF_INET:
pp := (*RawSockaddrInet4)(unsafe.Pointer(rsa))
sa := new(SockaddrInet4)
p := (*[2]byte)(unsafe.Pointer(&pp.Port))
sa.Port = int(p[0])<<8 + int(p[1])
for i := 0; i < len(sa.Addr); i++ {
sa.Addr[i] = pp.Addr[i]
}
return sa, nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
case AF_INET6:
pp := (*RawSockaddrInet6)(unsafe.Pointer(rsa))
sa := new(SockaddrInet6)
p := (*[2]byte)(unsafe.Pointer(&pp.Port))
sa.Port = int(p[0])<<8 + int(p[1])
sa.ZoneId = pp.Scope_id
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
for i := 0; i < len(sa.Addr); i++ {
sa.Addr[i] = pp.Addr[i]
}
return sa, nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
return nil, EAFNOSUPPORT
}
func Accept(fd int) (nfd int, sa Sockaddr, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var rsa RawSockaddrAny
var len _Socklen = SizeofSockaddrAny
nfd, err = accept(fd, &rsa, &len)
if err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return
}
if runtime.GOOS == "darwin" && len == 0 {
// Accepted socket has no address.
// This is likely due to a bug in xnu kernels,
// where instead of ECONNABORTED error socket
// is accepted, but has no address.
Close(nfd)
return 0, nil, ECONNABORTED
}
sa, err = anyToSockaddr(&rsa)
if err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
Close(nfd)
nfd = 0
}
return
}
func Getsockname(fd int) (sa Sockaddr, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var rsa RawSockaddrAny
var len _Socklen = SizeofSockaddrAny
if err = getsockname(fd, &rsa, &len); err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return
}
// TODO(jsing): Remove after OpenBSD 5.4 is released (see issue 3349).
if runtime.GOOS == "openbsd" && rsa.Addr.Family == AF_UNSPEC && rsa.Addr.Len == 0 {
rsa.Addr.Family = AF_UNIX
rsa.Addr.Len = SizeofSockaddrUnix
}
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return anyToSockaddr(&rsa)
}
func Getpeername(fd int) (sa Sockaddr, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var rsa RawSockaddrAny
var len _Socklen = SizeofSockaddrAny
if err = getpeername(fd, &rsa, &len); err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return
}
return anyToSockaddr(&rsa)
}
//sysnb socketpair(domain int, typ int, proto int, fd *[2]int32) (err error)
func GetsockoptByte(fd, level, opt int) (value byte, err error) {
var n byte
vallen := _Socklen(1)
err = getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&n)), &vallen)
return n, err
}
func GetsockoptInt(fd, level, opt int) (value int, err error) {
var n int32
vallen := _Socklen(4)
err = getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&n)), &vallen)
return int(n), err
}
func GetsockoptInet4Addr(fd, level, opt int) (value [4]byte, err error) {
vallen := _Socklen(4)
err = getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value[0])), &vallen)
return value, err
}
func GetsockoptIPMreq(fd, level, opt int) (*IPMreq, error) {
var value IPMreq
vallen := _Socklen(SizeofIPMreq)
err := getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value)), &vallen)
return &value, err
}
func GetsockoptIPv6Mreq(fd, level, opt int) (*IPv6Mreq, error) {
var value IPv6Mreq
vallen := _Socklen(SizeofIPv6Mreq)
err := getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value)), &vallen)
return &value, err
}
func GetsockoptIPv6MTUInfo(fd, level, opt int) (*IPv6MTUInfo, error) {
var value IPv6MTUInfo
vallen := _Socklen(SizeofIPv6MTUInfo)
err := getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value)), &vallen)
return &value, err
}
func GetsockoptICMPv6Filter(fd, level, opt int) (*ICMPv6Filter, error) {
var value ICMPv6Filter
vallen := _Socklen(SizeofICMPv6Filter)
err := getsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value)), &vallen)
return &value, err
}
func SetsockoptByte(fd, level, opt int, value byte) (err error) {
var n = byte(value)
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(&n)), 1)
}
func SetsockoptInt(fd, level, opt int, value int) (err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var n = int32(value)
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(&n)), 4)
}
func SetsockoptInet4Addr(fd, level, opt int, value [4]byte) (err error) {
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(&value[0])), 4)
}
func SetsockoptTimeval(fd, level, opt int, tv *Timeval) (err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(tv)), unsafe.Sizeof(*tv))
}
func SetsockoptLinger(fd, level, opt int, l *Linger) (err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(l)), unsafe.Sizeof(*l))
}
func SetsockoptIPMreq(fd, level, opt int, mreq *IPMreq) (err error) {
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(mreq)), unsafe.Sizeof(*mreq))
}
func SetsockoptIPv6Mreq(fd, level, opt int, mreq *IPv6Mreq) (err error) {
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(mreq)), unsafe.Sizeof(*mreq))
}
func SetsockoptICMPv6Filter(fd, level, opt int, filter *ICMPv6Filter) error {
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(filter)), SizeofICMPv6Filter)
}
func SetsockoptString(fd, level, opt int, s string) (err error) {
return setsockopt(fd, level, opt, uintptr(unsafe.Pointer(&[]byte(s)[0])), uintptr(len(s)))
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
//sys recvfrom(fd int, p []byte, flags int, from *RawSockaddrAny, fromlen *_Socklen) (n int, err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Recvfrom(fd int, p []byte, flags int) (n int, from Sockaddr, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var rsa RawSockaddrAny
var len _Socklen = SizeofSockaddrAny
if n, err = recvfrom(fd, p, flags, &rsa, &len); err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return
}
if rsa.Addr.Family != AF_UNSPEC {
from, err = anyToSockaddr(&rsa)
}
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return
}
//sys sendto(s int, buf []byte, flags int, to uintptr, addrlen _Socklen) (err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Sendto(fd int, p []byte, flags int, to Sockaddr) (err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
ptr, n, err := to.sockaddr()
if err != nil {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
return err
}
return sendto(fd, p, flags, ptr, n)
}
//sys recvmsg(s int, msg *Msghdr, flags int) (n int, err error)
func Recvmsg(fd int, p, oob []byte, flags int) (n, oobn int, recvflags int, from Sockaddr, err error) {
var msg Msghdr
var rsa RawSockaddrAny
msg.Name = (*byte)(unsafe.Pointer(&rsa))
msg.Namelen = uint32(SizeofSockaddrAny)
var iov Iovec
if len(p) > 0 {
iov.Base = (*byte)(unsafe.Pointer(&p[0]))
iov.SetLen(len(p))
}
var dummy byte
if len(oob) > 0 {
// receive at least one normal byte
if len(p) == 0 {
iov.Base = &dummy
iov.SetLen(1)
}
msg.Control = (*byte)(unsafe.Pointer(&oob[0]))
msg.SetControllen(len(oob))
}
msg.Iov = &iov
msg.Iovlen = 1
if n, err = recvmsg(fd, &msg, flags); err != nil {
return
}
oobn = int(msg.Controllen)
recvflags = int(msg.Flags)
// source address is only specified if the socket is unconnected
if rsa.Addr.Family != AF_UNSPEC {
from, err = anyToSockaddr(&rsa)
}
return
}
//sys sendmsg(s int, msg *Msghdr, flags int) (err error)
func Sendmsg(fd int, p, oob []byte, to Sockaddr, flags int) (err error) {
var ptr uintptr
var salen _Socklen
if to != nil {
ptr, salen, err = to.sockaddr()
if err != nil {
return
}
}
var msg Msghdr
msg.Name = (*byte)(unsafe.Pointer(ptr))
msg.Namelen = uint32(salen)
var iov Iovec
if len(p) > 0 {
iov.Base = (*byte)(unsafe.Pointer(&p[0]))
iov.SetLen(len(p))
}
var dummy byte
if len(oob) > 0 {
// send at least one normal byte
if len(p) == 0 {
iov.Base = &dummy
iov.SetLen(1)
}
msg.Control = (*byte)(unsafe.Pointer(&oob[0]))
msg.SetControllen(len(oob))
}
msg.Iov = &iov
msg.Iovlen = 1
if err = sendmsg(fd, &msg, flags); err != nil {
return
}
return
}
//sys kevent(kq int, change uintptr, nchange int, event uintptr, nevent int, timeout *Timespec) (n int, err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Kevent(kq int, changes, events []Kevent_t, timeout *Timespec) (n int, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
var change, event uintptr
if len(changes) > 0 {
change = uintptr(unsafe.Pointer(&changes[0]))
}
if len(events) > 0 {
event = uintptr(unsafe.Pointer(&events[0]))
}
return kevent(kq, change, len(changes), event, len(events), timeout)
}
//sys sysctl(mib []_C_int, old *byte, oldlen *uintptr, new *byte, newlen uintptr) (err error) = SYS___SYSCTL
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
func Sysctl(name string) (value string, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// Translate name to mib number.
mib, err := nametomib(name)
if err != nil {
return "", err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
// Find size.
n := uintptr(0)
if err = sysctl(mib, nil, &n, nil, 0); err != nil {
return "", err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
if n == 0 {
return "", nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
// Read into buffer of that size.
buf := make([]byte, n)
if err = sysctl(mib, &buf[0], &n, nil, 0); err != nil {
return "", err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
// Throw away terminating NUL.
if n > 0 && buf[n-1] == '\x00' {
n--
}
return string(buf[0:n]), nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
func SysctlUint32(name string) (value uint32, err error) {
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// Translate name to mib number.
mib, err := nametomib(name)
if err != nil {
return 0, err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
// Read into buffer of that size.
n := uintptr(4)
buf := make([]byte, 4)
if err = sysctl(mib, &buf[0], &n, nil, 0); err != nil {
return 0, err
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
if n != 4 {
return 0, EIO
}
return *(*uint32)(unsafe.Pointer(&buf[0])), nil
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
}
//sys utimes(path string, timeval *[2]Timeval) (err error)
func Utimes(path string, tv []Timeval) (err error) {
if len(tv) != 2 {
return EINVAL
}
return utimes(path, (*[2]Timeval)(unsafe.Pointer(&tv[0])))
}
os: Improve the accuracy of os.Chtimes I've been writing some code which involves syncing files (like rsync) and it became apparent that under Linux I could read modification times (os.Lstat) with nanosecond precision but only write them with microsecond precision. This difference in precision is rather annoying when trying to discover whether files need syncing or not! I've patched syscall and os to increases the accuracy of of os.Chtimes for Linux and Windows. This involved exposing the utimensat system call under Linux and a bit of extra code under Windows. I decided not to expose the "at" bit of the system call as it is impossible to replicate under Windows, so the patch adds syscall.Utimens() to all architectures along with a ImplementsUtimens flag. If the utimensat syscall isn't available (utimensat was added to Linux in 2.6.22, Released, 8 July 2007) then it silently falls back to the microsecond accuracy version it uses now. The improved accuracy for Windows should be good for all versions of Windows. Unfortunately Darwin doesn't seem to have a utimensat system call that I could find so I couldn't implement it there. The BSDs do, but since they share their syscall implementation with Darwin I couldn't figure out how to define a syscall for *BSD and not Darwin. I've left this as a TODO in the code. In the process I implemented the missing methods for Timespec under Windows which I needed which just happened to round out the Timespec API for all platforms! ------------------------------------------------------------ Test code: http://play.golang.org/p/1xnGuYOi4b Linux Before (1000 ns precision) $ ./utimetest.linux.before z Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST Reading mtime 1344937903123457000: 2012-08-14 10:51:43.123457 +0100 BST Linux After (1 ns precision) $ ./utimetest.linux.after z Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST Reading mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST Windows Before (1000 ns precision) X:\>utimetest.windows.before.exe c:\Test.txt Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 GMTDT Reading mtime 1344937903123456000: 2012-08-14 10:51:43.123456 +0100 GMTDT Windows After (100 ns precision) X:\>utimetest.windows.after.exe c:\Test.txt Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 GMTDT Reading mtime 1344937903123456700: 2012-08-14 10:51:43.1234567 +0100 GMTDT R=golang-dev, alex.brainman, rsc, bradfitz CC=golang-dev https://golang.org/cl/6905057
2012-12-13 14:02:39 -07:00
func UtimesNano(path string, ts []Timespec) error {
// TODO: The BSDs can do utimensat with SYS_UTIMENSAT but it
// isn't supported by darwin so this uses utimes instead
if len(ts) != 2 {
return EINVAL
}
// Not as efficient as it could be because Timespec and
// Timeval have different types in the different OSes
tv := [2]Timeval{
NsecToTimeval(TimespecToNsec(ts[0])),
NsecToTimeval(TimespecToNsec(ts[1])),
}
return utimes(path, (*[2]Timeval)(unsafe.Pointer(&tv[0])))
}
//sys futimes(fd int, timeval *[2]Timeval) (err error)
func Futimes(fd int, tv []Timeval) (err error) {
if len(tv) != 2 {
return EINVAL
}
return futimes(fd, (*[2]Timeval)(unsafe.Pointer(&tv[0])))
}
//sys fcntl(fd int, cmd int, arg int) (val int, err error)
syscall: Create syscall_bsd.go for code used by Darwin and other *BSDs In this change I'd like to combine the common code that is present in syscall_darwin.go and syscall_freebsd.go. I have three reasons for wanting to do this now: 1. reducing code duplication is nearly always good :-) 2. the duplication will get worse if I duplicate this code a third time for the NetBSD port I'm working on, which I need to do almost immediately 3. by making this change all in one lump and ignoring any commonality with the syscall_linux*.go files the diff is long but, I think, readable In future it may be possible to cherry pick functions that also apply to Linux and put them in (say) syscall_unix.go, and of course some functions may diverge in future and have to move out to OS or architecture specific files, but today I want just the low hanging fruit. Tested and passed on: Darwin (Snow Leopard, 10.6): amd64 and 386 FreeBSD (8.0-RELEASE): 386 only(*) (*) All my virtualisation software has stopped playing nice with FreeBSD for the moment, so I don't have facilities to test the amd64 port. As the OS X port is OK and the diff looks all right to my eyes I shall keep my fingers crossed. If someone with a FreeBSD/amd64 system cares to test and report I would be appreciative. 2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again. As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results. R=rsc CC=golang-dev https://golang.org/cl/751041
2010-03-26 14:23:54 -06:00
// TODO: wrap
// Acct(name nil-string) (err error)
// Gethostuuid(uuid *byte, timeout *Timespec) (err error)
// Madvise(addr *byte, len int, behav int) (err error)
// Mprotect(addr *byte, len int, prot int) (err error)
// Msync(addr *byte, len int, flags int) (err error)
// Ptrace(req int, pid int, addr uintptr, data int) (ret uintptr, err error)
var mapper = &mmapper{
active: make(map[*byte][]byte),
mmap: mmap,
munmap: munmap,
}
func Mmap(fd int, offset int64, length int, prot int, flags int) (data []byte, err error) {
return mapper.Mmap(fd, offset, length, prot, flags)
}
func Munmap(b []byte) (err error) {
return mapper.Munmap(b)
}