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
Archive for February, 2010
Quick Update: progressing slowly
Sunday, February 28th, 2010Two steps forward, one step back
Tuesday, February 23rd, 2010I 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
Distraction: Virtualisation Software Wars
Tuesday, February 23rd, 2010Short version: Arrghhh!
Long version:
For historical reasons (and some commercial software) my "own" machines run OS X. (Up until a week ago I had a ten year old x86 machine as well, but I’d used up all my spare parts, and wanted the cupboard space, so it had to go.)
Virtualisation (or “Virtualization”, depending on the version of English you write), you say. Didn’t I use to be an expert on that? (By most definitions, yup. But not on x86/x86_64.)
I have been using Parallels 4.x, and found it usable. I could (with arm twisting) get it to run NetBSD-4.0/i386 (32 bit, not 64 bit) and there were limitations with its networking support on OS/X.
Parallels keep encouraging me to buy their (now not-so-new) 5.x, and offer a trial version. So I tried it. (Emphasis on the past tense.)
- it won’t run NetBSD-5.0/amd64 any way I can figure out (a main target for a go port)
- it will run NetBSD-5.0/i386, and is fast (but I’m not so convinced about the stability)
- it runs Linux (surprise ☺)
- it won’t run FreeBSD-8.0/amd64, which I want for comparison purposes.
- its ACPI is … peculiar (And yeah, I know ACPI is overly complex and stupid. I even know what the acronym stands for. But we have to live with it these days, "the industry" tells us)
And they want money for this. Maybe I’d prefer to give my money to VMware.
But before I do anything rash, I try VirtulBox again. It’s updated a few versions since I used it last; it’s sorta-kinda-partly-at-least open source. Last time I ran it it had problems with NetBSD, ran slow, and caused my laptop to run hot.
This time, installs NetBSD-5.0 (i386 and amd64), with ACPI (gee, revolutionary in 2010, dontchathink?) and they’ve moved to include bridged networking on OS/X, which means I don’t have to run it on my laptop.
Looks like a winner. Except that it won’t run FreeBSD/amd64 any way I can figure out. (I am sure I saw it installing and losing access to its “disks”, but all subsequent attempts to boot it make it look like a 32 bit machine trying to boot a 64 bit kernel). It does run FreeBSD-8.0/i386, at least. And 32 and 64 bit Linux, of course.
Maybe I want VMware after all. Something that "just works" would be nice. Truly nice. Especially if it keeps working when I stress it, which isn’t necessarily going to be the case with any of them. (Or OS X, of course. Don’t mention the transitory network problem that I can’t pin down to hardware, software, or even a single machine yet.)
Rant for the day is now over. Progress might resume shortly.
Current patch list
Monday, February 22nd, 2010This 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, 2010This 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:
The in-progress diffs are maintained here:
–giles