Comments (4)
I want to know Why not choose to support x86-32? What are the considerations?
Hi @MichealZwen -- we'd love to do so; the only real issue is time and resources. As far as I'm aware, none of the Cranelift developers has the time to prioritize x86-32 support above all of the other things that we need to work on. It would probably be several months of fulltime work (1-2 months for someone already familiar with the codebase). If you or someone else is interested in working on this, I'd be happy to provide some pointers. Thanks and sorry I can't be of more help!
from lucet.
Lucet-wise, we'd strongly recommend moving from Lucet to Wasmtime (which these days also supports distinct compile/execute phases, and userfaultfd for memory management) - even if Cranelift did support x86-32, I think it's relatively unlikely that we'd land the necessary changes in lucet-runtime to support that. Lucet is primarily in a maintenance mode these days, and generally Wasmtime should be a viable replacement with the benefit that it's more actively up to date with work on WASM proposals, support for more architectures, and a better story for interop with various host languages.
For a sense of scale for x86-32 support in Lucet, I did a PoC of x86-32 support in Lucet a year or so ago that is still probably about right. This depended on an old x86 Cranelift backend that has since been deprecated and removed. (not a point against x86-32 support in Cranelift, the old x86-32 backend also needed some care before seeing real workloads too)
I see you mentioned ARM32 and ARM64; Lucet doesn't support ARM at all today, and would need more substantial changes for those architectures. Another point in favor of Wasmtime is that it already supports ARM32/ARM64. It doesn't make so much sense to repeat that work when Wasmtime does a great job with them already. While the code generator both runtimes use is shared, Lucet does not have support for architecture-specific details in running ARM code, meaning those architectures would also need some work like with the x86-32 PR I linked aboove.
As Chris noted, for Cranelift to support x86-32 in either Lucet or Wasmtime it'll need work either way, and I know I'd be super excited to see proper support for x86-32 in Cranelift, so please don't let me dissuade you if you're interested!
from lucet.
Ah, yes, I have just realized that this issue is on the Lucet repo and not Cranelift (my mistake, unified notifications inbox...); please interpret my comments above in the context of Cranelift generally :-)
from lucet.
I'd love to, but maybe I'm not familiar with codebase.
I'd like to consult you. How to do lightweight memory isolation in WASmTime or Lucet Runtime?
So far I see userFaultfd being used, but it seems like it can only notify the user layer of page faults in registered address spaces? This approach will not work if illegal access to a physical page is already mapped.
from lucet.
Related Issues (20)
- Errors while executing hello world example with lucetc-wasi HOT 5
- Arrch64:Do we have plan to support aarch64 HOT 1
- Add command-line option to `lucetc` to limit the globals size of produced modules.
- Reduce the reliance on strings in error types
- Difference between Lucet and other standalone Wasm runtimes like WAVM or Wasmer HOT 1
- LimitsExceeded("heap spec initial size: HeapSpec ... HOT 1
- Unable to get hostcall examples working: lucetc errors with both Rust and AssemblyScript version HOT 1
- CNCF-Runtime discussion/presentation
- cargo cannot resolve dependency HOT 3
- Rust runtime is unable to find symbol "main" of Hello World example HOT 1
- Aarch64 support: What is missing? HOT 2
- Calling guest function via get_func_from_idx() can trigger "Invalid Hostcall" HOT 2
- why is Lucet slower than wasmtime HOT 4
- Screencast in README is too fast to read HOT 2
- "Getting Started" link broken HOT 1
- Access Lucet from REST/Web Server? HOT 1
- lucet-runtime-example doesn't work when specifying latest crate version (0.6.1)
- RuntimeTerminated(TerminationDetails::BlockOnNeedsAsync) HOT 2
- [Documentation] seems a little bit outdated HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lucet.