-
Notifications
You must be signed in to change notification settings - Fork 11
Improve Lind Toolchain docs #231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current documentation about the Lind toolchain used for building and running Lind programs can be found in several docs under: https://github.com/Lind-Project/lind-wasm/tree/997a29c89f1d26e400f7f18eca062914f78c62c9/docs/build Some issues with the current documentation include: - lack of bigger picture (how do these tools relate?) - outdated - overly detailed (e.g. libc) - overly succinct (e.g. bazel) This patch adds a new single document, which gives an **overview** of the full Lind toolchain, and how it is built step by step, with references to Internal Documentation for background information about the toolchain, and build scripts (Docker, bazel, shell scripts) for detailed build commands and options. Note that I deliberately added the document under the *Usage* section, because I think it could fully replace all documents in the *Build System* section, and then probably wouldn't need its own top-level section on the website. Moreover, the *Usage* section seems like a good fit given the current experimental state of the project, where usage very likely involves tinkering with the toolchain. Signed-off-by: Lukas Puehringer <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can someone fill the gaps below? cc @Yaxuan-w, @rennergade, @qianxichen233
You can comment here and I add it to the PR. Or we merge first, and edit in new PRs.
|
||
3. __Build *glibc* and generate sysroot__ (see `make_glibc` in [BUILD](https://github.com/Lind-Project/lind-wasm/blob/main/BUILD) file) | ||
1. Configure and compile *glibc* for the *WASI* target with *Clang*. (see | ||
[`wasm-config.sh`](https://github.com/Lind-Project/lind-wasm/blob/main/src/glibc/wasm-config.sh)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's adds some information about the used build flags here, like the current build glibc doc does, but with better explanation of why these flags are are used with the given values.
Most notably, why do we use "i686-linux-gnu" as --host
and --build
argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- `nptl/pthread_create.c` | ||
- `lind_syscall/lind_syscall.c` | ||
- `csu/wasm32/wasi_thread_start.s` | ||
- `csu/wasm32/set_stack_pointer.s` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to add some extra information here, like a oneliner description of these files and why they need to be compiled separately?
I think it would also be worth to describe or give an overview of the used compiler flags. Most notably, what's with all the includes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lind_syscall/lind_syscall.c
: This file serves as the interface in glibc to redirect syscalls into Wasmtime. It’s specific to our lind-wasm setup and handles the syscall transition logic.nptl/pthread_create.c
,csu/wasm32/wasi_thread_start.s
,csu/wasm32/set_stack_pointer.s
: These three are related to our thread/multi-process support in lind-wasm. Some of the changes we made for enabling thread functionality involve these files.
I think @qianxichen233 could provide more detailed context here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe listing those files explicitly is too much detail for an overview-type document. Would it make sense to just say, that we compile a few extra files here, which are not part of glibc, but are needed in the sysroot for reasons XZY? Could you help with phrasing?
Maybe we could provide more details in the internal/libc.md
document.
Thanks @lukpueh ! I tagged @qianxichen233 here, I think he has the best answers for the specific questions you asked. Also tagging @m-hemmings to review. |
docs/use/toolchain.md
Outdated
in lind programs | ||
- A custom *WebAssembly* runtime ([`wasmtime`](../internal/wasmtime.md)) based | ||
on [*RawPOSIX*](../internal/rawposix.md) to run lind programs | ||
- Rust Cargo to build `wasmtime` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it common to refer to it as "Rust Cargo" or just "Cargo"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to emphasize the multi-lang nature of the project. But you're right, Rust Cargo sounds odd. What about Rust/Cargo? :D I'm also fine with just Cargo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a nit to pick, so whatever makes sense is fine with me, I can certainly appreciate wanting to emphasize that Cargo is a Rust tool
docs/use/toolchain.md
Outdated
and lind programs | ||
- A custom [*glibc*](../internal/libc.md) used as sysroot to build | ||
lind programs | ||
- A custom `wasm-opt` binary to enable [multi-processing](../internal/multiprocess-support.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the method of customization of either this or the following custom WebAssembly explained anywhere? Is it important to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I think the internal/*
documentation should and in parts already does elaborate on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can link to that in a footnote or something on this and expand on it in the appropriate place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's a bit more to this to do with signaling, hopefully @qianxichen233 can clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can link to that in a footnote or something on this and expand on it in the appropriate place
The word "multi-processing" here links to the internal documentation. Do you prefer a footnote? Or a different link text?
I can see how outlining just multi-processing, could look like it links to a general explanation of multi-processing. Adding the link to wasm-opt might be more helpful. The problem is, we currently don't mention wasm-opt in that text at all.
What do you think about moving the link to wasm-opt and create an issue for mentioning it in the mutli-processing doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about moving the link to wasm-opt and create an issue for mentioning it in the mutli-processing doc?
Just changed the link, will post an issue shortly.
- `nptl/pthread_create.c` | ||
- `lind_syscall/lind_syscall.c` | ||
- `csu/wasm32/wasi_thread_start.s` | ||
- `csu/wasm32/set_stack_pointer.s` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lind_syscall/lind_syscall.c
: This file serves as the interface in glibc to redirect syscalls into Wasmtime. It’s specific to our lind-wasm setup and handles the syscall transition logic.nptl/pthread_create.c
,csu/wasm32/wasi_thread_start.s
,csu/wasm32/set_stack_pointer.s
: These three are related to our thread/multi-process support in lind-wasm. Some of the changes we made for enabling thread functionality involve these files.
I think @qianxichen233 could provide more detailed context here
Reword based on review: - Clarify wasmtime/rawposix relationship - relocate link text to clarify what is linked to - Remove redundancy: "Rust Cargo" -> "Cargo" Signed-off-by: Lukas Puehringer <[email protected]>
Thanks for your comments. This is ready for another round of review |
A replacement was added with Lind-Project#231. Closes Lind-Project#232 (see issue description for details) Signed-off-by: Lukas Puehringer <[email protected]>
Current documentation about the Lind toolchain used for building and running Lind programs can be found in several docs under: https://github.com/Lind-Project/lind-wasm/tree/997a29c89f1d26e400f7f18eca062914f78c62c9/docs/build
Some issues with the current documentation include:
This patch adds a new single document, which gives an overview of the full Lind toolchain, and how it is built step by step, with references to Internal Documentation for background information about the toolchain, and build scripts (Docker, bazel, shell scripts) for detailed build commands and options.
Note that I deliberately added the document under the Usage section, because I think it could fully replace all documents in the Build System section, and then probably wouldn't need its own top-level section on the website. Moreover, the Usage section seems like a good fit given the current experimental state of the project, where usage very likely involves tinkering with the toolchain.
Note to reviewer: Please check..
See our add docs guide for how to build the docs site locally.
related #180 #196