On Wed, Oct 27, 2021 at 6:56 AM Richard Miller <9f...@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

Reply via email to