> Skip, did you specify -o cache=mmap when mounting diod service
> for the go build experiment?
I tried it myself using local diod and cache=mmap. I get a similar
SIGBUS on instruction fetch again. Conclusion: as Bakul says, now
I'm debugging linux. Not going there, thanks.
Going further off-topic for 9fans, sorry:
I thought it would be clever to update the linux client to a newer
kernel (4.19 was the latest I could find for debian 9). That
didn't go well: booting the new kernel fails with the message
Failed to find cpu0 device node
Does anyone know if it's feasible to do an out-of-tree build
of v9fs kernel modules (9p, 9pnet?) from current source [where
is it?] and use them with my old 4.9 kernel?
You can certainly try to do a _build_, and you may even get a shared object of some kind. Perhaps the question could be rephrased as, "will such a built artifact work in an older kernel?" and for that, I'm afraid all bets are off.
What, precisely, is your use case? I understood from your earlier note that you'd rather not keep data on Linux if you don't have to. But if you're only building, and the "data" is just a cloned git repository and object files and binaries, I'd reiterate my suggestion of plan 9 mounting a user-level 9P server from Linux instead of Linux trying to mount a 9P server from plan9: the data on Linux might be thought of as a cache, that's easily reconstructable if necessary. Perhaps another question is, why not build directly on plan9? Bootstrapping a toolchain, perhaps?
- Dan C.