Not all syscalls are implemented, but many are. On the suggestion
of Joel Sing <jsing@google.com>, the generated files were added
with hg add instead of hg cp, since they are generated on an OS
dependant basis.
R=golang-dev, jsing, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5491050
For now a pair of socket options SOL_SOCKET and SO_BINDTODEVICE
is supported on Linux only. I'd like to demote BindToDevice API
to syscall level because it's Linux dependent one.
In the near future, probably we may have a bit more portable
API that using IPROTO_IP/IPV6 level socket options to specify,
identify an inbound, outbound IP interface on incoming, outgoing
UDP and raw IP packets.
R=cw, golang-dev
CC=golang-dev
https://golang.org/cl/5447071
Work around a bug that was fixed after OpenBSD 5.0 - a request for
kern.hostname or kern.domainname with a nil value for oldp will result
in a length of zero being returned. If we hit this case use a length
of MAXHOSTNAMELEN (256).
R=golang-dev, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5408041
Move the existing darwin/freebsd specific nametomib implementation
into the respective operating system dependent files.
Provide a nametomib implementation for openbsd, which operates on a
sysctl MIB that has been pre-generated from the various system headers
by mksysctl_openbsd.pl.
R=rsc
CC=golang-dev
https://golang.org/cl/4935044
The environment is needed by package time, which
we want not to depend on os (so that os can use
time.Time), so push down into syscall.
Delete syscall.Sleep, now unnecessary.
The package os environment API is preserved;
it is only the implementation that is moving to syscall.
Delete os.Envs, which was undocumented,
uninitialized on Windows and Plan 9, and
not maintained by Setenv and Clearenv.
Code can call os.Environ instead.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5370091
- syscall (not os) now defines the Errno type.
- the low-level assembly functions Syscall, Syscall6, and so on
return Errno, not uintptr
- syscall wrappers all return error, not uintptr.
R=golang-dev, mikioh.mikioh, r, alex.brainman
CC=golang-dev
https://golang.org/cl/5372080
The go/build package already recognizes
system-specific file names like
mycode_darwin.go
mycode_darwin_386.go
mycode_386.s
However, it is also common to write files that
apply to multiple architectures, so a recent CL added
to go/build the ability to process comments
listing a set of conditions for building. For example:
// +build darwin freebsd openbsd/386
says that this file should be compiled only on
OS X, FreeBSD, or 32-bit x86 OpenBSD systems.
These conventions are not yet documented
(hence this long CL description).
This CL adds build comments to the multi-system
files in the core library, a step toward making it
possible to use go/build to build them.
With this change go/build can handle crypto/rand,
exec, net, path/filepath, os/user, and time.
os and syscall need additional adjustments.
R=golang-dev, r, gri, r, gustavo
CC=golang-dev
https://golang.org/cl/5011046
The mmap system call varies across BSDs. Move mmap and munmap into
the operating system dependent files. This will be needed to add
syscall support for OpenBSD.
R=rsc
CC=golang-dev
https://golang.org/cl/4822056
Not all BSDs have the same pipe() syscall implementation - move the Darwin/FreeBSD specific implementation into their respective OS syscall files. This will be needed to add OpenBSD syscall support.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4823057
Add IPv6Mreq and Inet6Pktinfo for specifying the network interface.
Rename IpMreq to IPMreq, SetsockoptIpMreq to SetsockoptIPMreq.
R=rsc, dave, robert.hencke
CC=golang-dev
https://golang.org/cl/4532098
* tweak mksyscall*.pl to be more gofmt-compatible.
* add mkall.sh -syscalls option.
* add sys/mman.h constants on OS X
R=r, eds, niemeyer
CC=golang-dev
https://golang.org/cl/4369044
Moved the details of how to read a directory
and how to parse the results behind the new
syscall functions ReadDirent and ParseDirent.
Now os needs just one copy of Readdirnames
for the three Unix variants, and it no longer
imports "unsafe".
R=r, r2
CC=golang-dev
https://golang.org/cl/4368048
Permit system calls to be designated as non-blocking, meaning
that we simply call them without involving the scheduler.
This change by itself is mostly performance neutral. In
combination with a following change to the net package there
is a performance advantage.
R=rsc, dfc, r2, iant2, rsc1
CC=golang-dev
https://golang.org/cl/4278055
notes:
* due to Issue 1466 the Msghdr struct for
src/pkg/syscall/ztypes_darwin_386.go
src/pkg/syscall/ztypes_darwin_amd64.go
had to be edited after the godefs generation.
* ztypes_*.go files for linux, freebsd and darwin
have been prepared on the correct host OS and ARCH.
While the total increase is a dozen lines per file
the diff is larger due to a change to godefs,
http://code.google.com/p/go/source/detail?r=c79e30afe9c8
while has altered the names of Pad members which
causes gofmt to realign the affected structs
R=rsc, mikioh
CC=golang-dev
https://golang.org/cl/4119053
THIS WILL BREAK THE BUILD.
The z files have socketpair code in them that was
written by hand; breaking the build with this is the first
step in getting rid of that hand-written code.
R=adg
TBR=adg
CC=golang-dev
https://golang.org/cl/2197050
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
