zed-industries
RISC-V Linux support for zed-remote-server
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
Simple, if you have a computer with a weird CPU arch (i got a riscv SBC): try to ssh using zed into the remote computer and the issue will pop.
Environment
Zed in flatpak (shouldn't be an issue, i guess zed checks the arch of the remote host for some reasons).
If applicable, add mockups / screenshots to help explain present your vision of the feature
Simple: riscv, although being an alien-ish arch, still works with standards of x64 and arm in terms of apps. The openssh (riscv-64) server communicates well with my client (x64), i wonder why this check exists in the first place.
If it's indeed an error, then perhaps we could remove it ?
If applicable, attach your Zed.log file to this issue.
Zed.log
2024-10-19T13:29:27.87198325+02:00 [INFO] ========== starting zed ========== [useless logs] 2024-10-24T20:49:48.796929952+02:00 [INFO] Creating a descriptor pool for at most 16 sets 2024-10-24T20:49:48.802201331+02:00 [INFO] Creating a descriptor pool for at most 16 sets 2024-10-24T20:49:48.809196195+02:00 [INFO] Creating a descriptor pool for at most 256 sets 2024-10-24T20:49:48.816465935+02:00 [INFO] Creating a descriptor pool for at most 256 sets 2024-10-24T20:56:40.788410607+02:00 [ERROR] unknown uname architecture "riscv64\n"
In addition to SSH, Zed Remoting requires a process to run on the remote: zed-remote-server which must be compiled for the specific os and arch. We currently ship pre-compiled remote-server binaries for macOS and Linux on aarch64 and x86_64. SSH is used to connect, download/spawn the remote server and plumb the communication with the Zed GUI, but having OpenSSH is not enough for Zed Remoting to work we need that remote server process.
Additionally, even with that you may find that pre-compiled language server binaries (rust-analyzer, clangd, etc) are not available for your RISC-V system which are required for autocomplete and other advanced editing functionality.
To my knowledge there hasn't been much work to get the Zed remote daemon built for architectures other than aarch64/x86_64 (riscv64gc, LoongArch64 MIPS, s390x, powerpc, etc) although I expect that will be in some ways easier than adding 32bit support (riscv32, armv7, 32bit x86, etc).
Curious what Linux distribution are you running and on what arch/hardware you're looking to use.
In addition to SSH, Zed Remoting requires a process to run on the remote:
zed-remote-serverwhich must be compiled for the specific os and arch. We currently ship pre-compiled remote-server binaries for macOS and Linux on aarch64 and x86_64. SSH is used to connect, download/spawn the remote server and plumb the communication with the Zed GUI, but having OpenSSH is not enough for Zed Remoting to work we need that remote server process.Additionally, even with that you may find that pre-compiled language server binaries (rust-analyzer, clangd, etc) are not available for your RISC-V system which are required for autocomplete and other advanced editing functionality.
To my knowledge there hasn't been much work to get the Zed remote daemon built for architectures other than aarch64/x86_64 (riscv64gc, LoongArch64 MIPS, s390x, powerpc, etc) although I expect that will be in some ways easier than adding 32bit support (riscv32, armv7, 32bit x86, etc).
I see thanks for the explanation !
Curious what Linux distribution are you running and on what arch/hardware you're looking to use.
For that specific case, i use nixos, i've learnt later on that because of the FHS non-compliant nature of NixOS, Zed tends to not work as intended, even if the ssh connection could work on riscv. I guess i might take a closer look into it, after all zed seems to work on NixOS desktop sessions, so why not with an ssh session...
As for the hardware: star64 SBC from Pine64, it's not much but it has honest performance. It's a shame riscv doesn't have more support tho. It has potential but as is, it's not a great consumer choice unfortunately.
PS: Nix Flake with my SBC config if anyone is interested
Additionally, even with that you may find that pre-compiled language server binaries (rust-analyzer, clangd, etc) are not available for your RISC-V system which are required for autocomplete and other advanced editing functionality.
They are (and Node and everything else you might need). And working fine with Codium after linking the global binaries to the remote install directory, which does support RISCV64 (not VS Code).
Btw. I'm not sure if the current state of 3D acceleration support on RISC-V64 is sufficient to be able to run Zed's GUI, and I can't test it as the Armbian/Debian I use doesn't support my GPU (a Banana Pi BPI-F3 with a Spacemit K1 CPU).
The most important 2 things still missing or really incomplete on RISC-V64 are vector extensions (there are only 2 available CPUs that support them AFAIK) and 3D hardware acceleration apart from the most basic OpenGL features.
As per my comment, I can build a remote-server for riscv64 with a couple of dependency bumps.
The toolchain I used to compile it on my RISC-V dev board is 1.81-riscv64gc-unknown-linux-gnu.
But now I am a bit confused about the naming.
https://github.com/zed-industries/zed/blob/0a28800049e2a7e9093e870c5a4e4ad83aa80430/docs/src/remote-development.md?plain=1#L118
I want to access my dev board from my M1 Mac with my compiled remote-server. So, on my dev board, I moved it to ~/.zed_server/ and renamed it as zed-remote-server-preview-linux-riscv64. Then I got this when opening a remote on my Mac.
I saw the doc was edited by @ConradIrwin , so perhaps you could help with it?
Update:
I skimmed through the code https://github.com/zed-industries/zed/blob/0a28800049e2a7e9093e870c5a4e4ad83aa80430/crates/remote/src/ssh_session.rs#L1543
It seems now only whitelisted OSs and architectures can be accessed remotely. The restriction is imposed by the client-side Zed, which I think is a bit over-restrictive (but understandable for betas). In theory, on a machine, as long as remote-server can be compiled and ssh is available, this machine can be remotely accessed.
Sorry about this, it's all changed quite a bit between stable and preview, and I haven't updated the docs.
The thing to ensure is that the remote server version must match the zed version exactly (same commit / tag). This is hopefully something we can relax in the future, but right now changes are happening pretty fast between the two and not having to worry about forward/backward compatibility is nice.
If you're using the stable version of Zed, things will fail because it does the architecture check before checking to see if the binary is the correct version.
As of #20220 (which is in v0.161.0+, currently in preview), this has changed. It will first look for a binary at zed-remote-server-preview-0.160.1 and try to run it. If that doesn't work, then it will attempt to download (and fail because we don't publish risc64 binaries).
I'll update the docs, and improve the error message to link to them.
What kind of machines run risc64? If there's a way to boot up a reasonably quick one in the cloud, we could potentially publish these too (though it's getting into a bit of ropey ground, because risc64 isn't as well supported by rust itself as our other platforms).
OK, thanks for the clarification!
What kind of machines run risc64? If there's a way to boot up a reasonably quick one in the cloud, we could potentially publish these too.
I don't know how Rust project manages to build riscv64 rustc, but I saw Scaleway providing riscv64 servers, claiming to be the first riscv cloud. See this announcement and link.
What kind of machines run
risc64? If there's a way to boot up a reasonably quick one in the cloud, we could potentially publish these too (though it's getting into a bit of ropey ground, because risc64 isn't as well supported by rust itself as our other platforms).
If you don't need to do anything special with the hardware, Qemu is your best bet. Qemu on a reasonable fast machine is at least as fast as "normal" RISSC-V64 CPUs. E.g. my M1 Max using Qemu with 8 Cores is about as fast as a Spacemit K1 with 8 Cores, the C910 Scaleway uses is about the same.
I haven't had any special problems (just don't use the vector support, which almost all current CPUs don't support anyways) building stuff with Rust on RISC-V64 (Debian), rustc is really, really slow (haven't build Zed, a full Helix build takes about 45 Minutes), but still usable (Haskell is unusable slow).