Posts Tagged ‘syscall’

Non-NetBSD CLs, sycall, heading for runtime

Tuesday, April 20th, 2010

I’ve been distracted lately: Real Life took over again for a bit, and I’ve been wrangling some more general CLs through as I simultaneously learn the Go team’s processes for working with outsiders and attempt to reduce existing code duplication etc that I’d otherwise have to make worse. (My unpaid project: I work on whatever I want in what order I want. Still, I’d like to have had more time and more progress by now.)

In general, I think the NetBSD port can be pushed past the syscall stuff I got distracted by with a few sessions more work, then it’s into the runtime with a vengance, where I believe the difficult work is hiding: setting up the support for goroutines on NetBSD 5.x’s light weight processes. Whee, another threading implementation to learn, on an unfamiliar (to me) architecture. I suppose learning some x86 assembler won’t hurt me too badly….

Progress, not always via the shortest path

Saturday, March 27th, 2010

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.)

Syscall proceeding; end in sight

Tuesday, March 23rd, 2010

After fighting a bit with the not-entirely-obvious format of NetBSD’s syscalls.master file, and leaning heavily on the existing Darwin and FreeBSD ports, I’m closing on a syscall package that will compile.

The two next steps (that I’m cognizant of!) are:

1. deal with the ELF branding so that NetBSD binaries are generated
2. make it all actually work :)

I’ve been a little suprised at just how many system calls are not implemented in the current ports. For a language with aspirations to system programming, I hope that’s just “get 1.0 out the door” haste and not a reluctance to expose all the OS’s functionality.

Quick Update: progressing slowly

Sunday, February 28th, 2010

Still working, nothing much more to show. The syscall package is being beaten into behaving.

I’ve received one offer to beta test; be sure I’ll post here (and to the NetBSD mailing lists) when I get to alpha and beta testing stages.

Cheers,

Giles

Two steps forward, one step back

Tuesday, February 23rd, 2010

I better understand now how the pkg/syscall/z*.go files are generated. That’s the good news, part 1.

The good news part 2 is that with a working NetBSD/amd64 host, I have filled in placeholders similar to the 386 files in the pkg/runtime/amd64 directory.

The not so good news is back in pkg/syscall, where I’ve stripped syscalls_netbsd.go back to basics and am filling it based on analysis of NetBSD’s syscalls.master file. Just copying from FreeBSD or Darwin wasn’t going to cut it.

The updated patches have been uploaded in case anyone’s really curious (and it gets me an offsite backup) but they’re still some way off being useful.

–giles