Archive for the ‘NetBSD’ Category

*ping*

Sunday, April 4th, 2010

Still working, kinda.

I’m being held up by the number of bugs I’m finding (and taking the time to try to get fixed) and that the go-devel team have gone and gotten distracted (best case) with their panic()/recover() feature and aren’t reviewing many CLs just now.

There hadseemed little point in pushing on with local patches to the main Go code when I can submit a CL (and until recently) get it committed promptly. If I can’t do that, the appropriate thing to do is perhaps just to push along with the port, accepting things that don’t work, putting in extra workarounds, and duplicating even more code, crossing my fingers that it’ll be able to be cleaned up one day.

My software development experience suggests it’s better to get it right the first time as it’s almost always impossible to go back, so I’m reluctant to change tack, but maybe I need to, if Go is to run on NetBSD.

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.

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

Current patch list

Monday, February 22nd, 2010

This is the current patch list, in the order I apply them. (Curently I don’t think the order matters, but in case it does, here’s what I use)):

noparallel

This one’s trivial, and won’t be needed in the final port. It merely turns off the “-j4” option in the build, which makes reading the build output easier. (Sure, it might slow down the build too, but I’m working on a virtual machine anyway, so speed’s not of the essence.)

netbsd

Minor bits and pieces to include NetBSD as a valid build target. Nothing interesting here, move along.

libmach

This will need some work, and honestly I don’t know what it requires yet. For now, I have just copied the FreeBSD port which has left a whole lot of functions stubbed out. I presume those functions do something useful, but until I know what they’re used for I don’t know what to implement. As for now they’re not stopping me working on the rest of the build, the placeholders get to stay.

runtime

This patch is for all the stuff under $GOROOT/src/pkg/runtime/. As it involves low level kernel access and provides facilities like semaphores and thread support, it’s important. It is also an area in which NetBSD is almost completely different from OS X (a.k.a. Darwin), Linux, and FreeBSD. Plus to make things even more complicated, the existing ports have all used low level OS specific features in preference to higher level standardised features such as the pthreads library supplies. Doubtless there is a reason (or reasons!) for this, but all I have so far is speculation.

Work here isn’t progressing very fast: I want to think about it some more, and have found simpler and more obvious work to go on with in the next patch.

syscall

This patch is for all the code under $GOROOT/src/pkg/syscall/. It includes things like system call numbers, errno values, and translations between C and Go types. Conceptually it’s not too difficult; in practice it requires creating some material by hand, and writing scripts to create other source files. I’d hoped this would be almost idenitcal to the FreeBSD port, but it turns out there are some divergences between FreeBSD so it’s not as simple as cut & paste.

This patch isn’t done yet, but it’s not far off, and then I think I’ll return to the runtime changes.

Hello world!

Sunday, February 21st, 2010

This blog is intended to record progress on porting Google’s Go language to NetBSD. There is an open item #611 in Google’s issue tracker for this.

Initial efforts are going to concentrate on the 386 (a.k.a. i386) and amd64 ports; in theory it should be possible to port to NetBSD arm platfoms as well.

As yet there’s no mailing list: should there be desire for one, I’ll create one. For now, feel free to add comments to the blog, which I’ll endeavour to keep updated as I update the patches.

All assistance is welcome. Feel free to dig in. No questions are too foolish to ask!

There’s a page of general information here:

http://netherstone.org/golang/netbsd/

The in-progress diffs are maintained here:

http://netherstone.org/golang/netbsd/patches/

–giles