Progress, not always via the shortest path

Still working away at the syscall package. It’s getting close now; the compilation errors are just about sorted, and I took a closer look at the wrapper functions in syscall_freebsd.go and syscall_darwin.go to pick out what I wanted (hoping of course that some of the remaining compilation issues would then be moot).

What I found was that I needed the same wrappers … and thought that duplicating them a third time would be a Bad Idea. So I spent some time in the existing syscall code reducing the duplication:

http://codereview.appspot.com/751041/show

I suspect some more work can be done — there is likely code that can be shared with Linux too — but this was the easy way to begin, and reduced the size of syscall_netbsd.go substantially.

A variant of the cleanup work is to review the list of system calls that Darwin, FreeBSD, and (eventually) NetBSD support. There doesn’t seem a lot of point to me in supporting munmap() if you don’t support mmap()! (There’s a vague rationale actually: munmap() will compile OK via mksyscall.sh. mmap() won’t, so leaving it “as is” defers the decision making about whether mmap() is useful or not (probably?) in a language without pointer arithmetic, and let the Darwin and later FreeBSD ports get “out the door” without waiting to decide.)

Tags: , , ,

Leave a Reply