Go is a fun esoteric language that strives for system-level usage. Currently in all real operating systems, C is the dominant systems language and as such, all the functionality for interfacing with core features are exposed as raw C APIs. Go provides a C FFI layer called cgo, which handles all the preprocessing and linking magic in the background. Unfortunately, there’s little-to-no documentation available for cgo, just a couple of toy examples in Go’s misc/cgo directory (there’s actually a shitton of production examples in the Go package sources though — fucking everything uses cgo).

So, what I want to do is expose getmntinfo, which simply lists the metadata for all mounted filesystems. In C, this is pretty trivial:

#include 
#include 
#include 

#include 

int main() {
        struct statfs *bufs;
        int i = getmntinfo(&bufs, 0);
        int j = 0;

        for (j = 0; j < i; ++j) {
                struct statfs fs = bufs[j];
                printf("[%s] %s -> %s\n", fs.f_fstypename,
                        fs.f_mntfromname, fs.f_mntonname);
        }

        return 0;
}

This, however, presents a variety of problems for the Go implementation –

1. We don’t really know how many struct statfs we’re getting back.
2. The memory allocated is actually allocated statically; we just get an opaque pointer back to an in-library address.
3. The fields of struct statfs are char[N]s rather than char*s.

Thankfully, calling getmntinfo is pretty trivial –

func GetMntInfo() []MntInfo {
        var tmp *C.struct_statfs;
        i := int(C.getmntinfo(&tmp, 0))

It’s pretty close to the C version — we just allocate a pointer, and pass a pointer to it in. getmntinfo sets the value of the pointer to an internal array of struct statfs‘s and lets us go along our merry way. Naturally, we want to marshal it to the appropriate Go types.

        info := make([]MntInfo, i)
        for j, _ := range(info) {

So we create an array to marshal values into and begin to iterate through it.

This is where it gets nasty. All we have right now is an opaque pointer to a struct statfs — in C we’d just use pointer arithmetic to get the other entries in the array. Go, fortunately, explicitly disallows pointer arithmetic. I’m not sure what the appropriate method to get values out of it is. First, I tried something like

foo := (*[]MntInfo)(unsafe.Pointer(tmp))
item := (*foo)[j]

But that seems to cause a panic (no idea why). I got tired of dicking with it and threw in the cards, simply exposing the following C function in the cgo header –

struct statfs* offset(struct statfs *v, int i) {
        return v + i;
}

With that, there’s no need to dick with much of anything, so we can get the current struct statfs of the iteration pass via

                s := C.offset(tmp, C.int(j))

Finally, the char[16] values need to be marshaled out. Unfortunately, the C.GoString marshaling function only takes a char* and it’s too damn stubborn to take an implicitly-convertible type (noting that X* != X[]). The other beef is that cgo’s type system processes a char[] strangely as a []_C_char_type, so we can index it perfectly fine (but not implicitly coerce it into a pointer).

So we juggle some types and shit all over unsafe.Pointer and make it do what we want –

                info[j].FsType = C.GoString((*C.char)
                        (unsafe.Pointer(&s.f_fstypename[0])))
                info[j].MntFrom = C.GoString((*C.char)
                        (unsafe.Pointer(&s.f_mntfromname[0])))
                info[j].MntOn = C.GoString((*C.char)
                        (unsafe.Pointer(&s.f_mntonname[0])))
        }

        return info
}

And, after several hours of not finding any fucking documentation and screaming at the fucking monitor the damn thing finally works. I’m completely glossing over the terrible shitty build system they’ve got set up (it basically only provides functionality to INSTALL to built cgo packages — I haven’t found a way to actually build and link them otherwise) — will probably have to read through all the fucking makefiles that do evil shit.

At some point just doing everything in C is easier, I suspect :|

---

will post full code listing in a sec

4 comments