On Wed, Oct 27, 2021 at 6:56 AM Richard Miller <9fans@hamnavoe.com> wrote: > > 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. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Maf2662944c3fcc3c671ade36 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription