Posts Tagged ‘NetBSD’
Monday, June 7th, 2010
Well, I have an update: I’ve pulled the plug.
Rationale: I’m giving up on Go. The language (IMHO, naturally) is not a “systems programming language” while it discourages access to system calls, and has only an (undocumented and weak) facility for accessing other operating system APIs.
Similarly, having Unicode and UTF-8 is great … but if you can’t even normalise a UTF-8 string, then comparisons (and sorting) degenerate to byte comparisons. I suppose it works for ASCII ….
There are other items of friction, both linguistic and process wise, but in short: I don’t see the value of putting my time into a port, and am pulling the plug.
Game over.
Tags: Go, golang, NetBSD, the end, unicode, utf-8
Posted in Uncategorized | No Comments »
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….
Tags: Go, golang, goroutines, lwp, NetBSD, runtime, syscall
Posted in Uncategorized | No Comments »
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.
Tags: NetBSD, Parallels, VirtualBox, virtualisation, VMware
Posted in Hardware, virtualisation | No Comments »
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.
Tags: Go, golang, Google, NetBSD, Politics
Posted in Go, Google, NetBSD, Politics | No Comments »
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.)
Tags: Go, golang, NetBSD, syscall
Posted in Go, Go Language Design, NetBSD | No Comments »
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.
Tags: Go, golang, NetBSD, syscall
Posted in Go, NetBSD | No Comments »
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.
Tags: Go, golang, NetBSD
Posted in Uncategorized | No Comments »
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.
Tags: Go, golang, NetBSD, patch
Posted in Go, NetBSD | No Comments »
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
Tags: Go, golang, NetBSD
Posted in Go, NetBSD | No Comments »