Archive for March, 2010

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

Aside: libc, errno, and OS functionality

Tuesday, March 23rd, 2010

In playing with writing some Go code (and not working on the NetBSD port!) I wanted to use some functionality that was in libc.

Now, I know that the Go developers don’t want to link in libc: quite why I’m not sure (I am confident they have their reasons, and can think of several good ones) but it presents a problem: when an OS vendor exposes functionality only as an API in libc, one is left using cgo to access it.

Worse, while I respect what cgo manages, I hit its limits pretty easily, and one limit isn’t at all easy to deal with: indeed, I don’t think it can be dealt with without support from the Go runtime. That case is errno. Regrettably, there are some libc functions that require clearing errno before calling the function, and checking it again afterward. Not good design but enshrined in history and in POSIX, so we’re kinda stuck with it now.

I thought about this for a while, and then realised that the problem is intractable outside the Go runtime, as Go multiplexes multiple goroutines onto individual OS threads, and errno is a per-thread (not, currently at anyrate) a per-goroutine variable.

I imagine the same problems will arise with any APIs which use thread local storage.

Bottom line: Unix errno and threads barely play together, and for the moment at least the Go runtime sweeps the problem under the carpet. Which may be the most sensible thing to do.

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.

Not sleeping, just resting

Wednesday, March 10th, 2010

Another “no news” post. As I gather minutes here and there I’m still working in the syscall package. (Backups are good. Up to the minute backups are best …)

My minutes are limited right now due to a family illness. (Prognosis very good, but some way to go.)

I’ve been making some small non-porting related contributions to Go which haven’t required as much mental energy to at least stay in touch.

Still working …

Friday, March 5th, 2010

Distracted by reinstalling my notebook and some Real Life “stuff”, the slow progress continues.

I have a script that largely massages syscalls.master into something I want to work on.

Further work is needed on types, on deciding what system calls not to expose, and which system calls need wrapping.