x/sys/unix: Missing constants for fadvise()

[fd0]

1. What version of Go are you using (go version)?
   go version go1.6 linux/amd64
2. What operating system and processor architecture are you using (go env)?
   Archlinux on amd64:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/fd0/shared/work/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?
   If possible, provide a recipe for reproducing the error.
   A complete runnable program is good.
   A link on play.golang.org is best.

The program at https://gist.github.com/6587a615cea63183676e2f2887d59d62 uses Fadvise from the unix package to purge data written to a file from the OS cache. The constants for this function (FADV_*) are defined in types_linux.go, but cannot be accessed from the outside of the unix package. This makes using Fadvise() awkward because I need to define the constants myself.

For the reference, here are the constants I'm missing:
https://github.com/golang/sys/blob/master/unix/types_linux.go#L175-L185

Running GOOS=linux GOARCH=amd64 mkall.sh inserts the constants into ztypes_linux_amd64.go.

I'm happy to submit a CL if someone gives me a hint on how to fix this.

1. What did you expect to see?

The FADV_* constants (e.g. FADV_DONTNEED) exported in the package unix.

1. What did you see instead?

FADV_DONTNEED is either not defined or not exported in the package, so users need to define that themselves.

[fd0]

@bradfitz can you advise me how to fix this? I'd be happy to submit a CL :)

When running mkall.sh, many more things are changed besides the introduction of the missing constants...

[ianlancetaylor]

Add the constants to x/sys/unix/types_*.go, run mkall.sh, revert the unrelated changes. Some day we will clean up mkall.sh, and if you want to tackle that that would be great, but you don't have to.

[fd0]

Submitted as https://go-review.googlesource.com/#/c/21753/, thanks for the advice.

[gopherbot]

CL https://golang.org/cl/21753 mentions this issue.