Non-Linux hosts

[mejedi]

This tool could enable ebpf development (or rather the testing aspect of it) on non-Linux platforms.

As far as I can tell the only obstacle so far is that vimto doubles as init which obviously won't work due to arch mismatch. (Another limitation is that it will only work with binaries produces by GOOS=linux go test, but that's already very useful.)

I could imagine vimto go:embeding its own sources on non-Linux platforms and building init on demand.

How much out of scope this feature is? Happy to contribute a patch.

[lmb]

Yeah, I have thought about doing this as well. My worry is that there aren’t that many cases where this would be truly useful. The current model would only work for tests that don’t have any external dependencies. For example c/ebpf/link depends on a bash binary to be able to test uprobes. We would have to ship that as part of the kernel image or similar. The other problem is that I want to add integration with delve, which also needs to be available in the target arch.

My gut feeling is that it would be better to flesh out the features and then see how non-Linux (aka macOS) could fit.

[mejedi]

Thank you for taking the time to respond.

My worry is that there aren’t that many cases where this would be truly useful. The current model would only work for tests that don’t have any external dependencies.

True, but that's already a lot. Most tests can be written this way (what's so special about uprobes? could target the current process). I do understand that it might be less useful for Cilium as it already has tests written in a certain way. It will benefit other projects though, including the one I'm affiliated with.

I've recently realised that it would be nice for things running in a VM to be able to create files on the host. E.g. we have tests for interacting XDP/TC programs and we capture PCAP files to assist in debugging test failures.

This wish has interesting implications: if we ever augment host filesystem via overlay (e.g. touch resolv.conf or merge in additional layers), it stops working.

It would be nice to have a coherent idea going forward how does the filesystem in the VM look like. What is more useful

• expose host filesystem fully, or
• expose only certain subtrees such as $HOME and /tmp.

Regardless, I learned that go install puts things in a different folder if one requests foreign architecture. It means that I can simply go install vimto twice which would give me a runnable init. It lowers the perceived effort considerably, so I think I am going to play with it just for fun.

The other problem is that I want to add integration with delve, which also needs to be available in the target arch.

That's cool! It would be handy to run delve in a screen session, so that it is possible to stream trace_pipe concurrently or even run bpftrace.