Archive for April, 2010

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

Virtualisation wars, part II

Monday, April 5th, 2010

OK, VirtualBox blew up again. So I blew it away.

All I want is something that can run Linux (64 and 32 bit), FreeBSD (64 and 32 bit) to check that I am not breaking anything, and NetBSD (64 and 32 bit) for the actual port. OS X I can run natitvey.

I can run one 32 bit OS otherwise on hardware I already own, and it doesn’t have enough memory to support virtualisation of an additional OS.

1. Paralells – insane cackling. 4.x didn’t work, 5.x is less stable and still doesn’t work, forget it
2. VirtualBox — works, but prone to introducing network errors and every so often decides that it will only boot FreeBSD in 32 bit mode, which works “badly” for 64 bit kernel
3. VMware doesn’t support NetBSD, my target platform.

Bugger. Bugger. Bugger.

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