Component model strategy for embedded
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- wasm
- Área
- embedded-iot
Línea de trabajo
Comienza con el enlace a component-model design/mvp/BuildTargets.md y con el issue 369 de component-model al que se hace referencia. Compara la representación propuesta del módulo principal, el enfoque basado en bibliotecas compartidas y los búferes proporcionados por el llamador, pero el issue no define un objetivo de implementación concreto ni criterios de aceptación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Dear Chris, sorry for taking quite long to read and reply to your proposal!
I see a potential path to combine preview1 and 0.2/0.3 - by using a core module binary representation of a "component" (this involves the "cm32p2|" naming of symbols https://github.com/WebAssembly/component-model/blob/add-build-targets/design/mvp/BuildTargets.md (and was previously called "wasit2")), potentially even compiled as a shared library (to achieve the relocatability of the data section) - but this sacrifices the insulation between modules. Insulation would require multi-memory, basically the wasip2 module file format is best suited for insulation.
To get the overhead of the canonical ABI down, caller provided buffers described in https://github.com/WebAssembly/component-model/issues/369 are most promising. I clearly aim for reducing the heap memory allocation overhead per call down to zero using the shared memory buffer mechanism because of real-time constraints and functional safety argumentation.
I am sorry, that even though there is good progress on definition and implementation, these technologies are not yet available right now.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 15
- Forks
- 5
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de bytecodealliance/sig-embedded
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
bytecodealliance/sig-embedded#22 · 1 comentario · 1 reacción ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Technical Note E-SIG -> SG : Area 3 Support for maintaining the existing tooling for WASI Preview 1Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
bytecodealliance/sig-embedded#19 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
bytecodealliance/sig-embedded#7 · 9 comentarios · 1 reacción ·
Todos los issues de bytecodealliance/sig-embedded
Issues similares
-
Status: Opened
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
raspberrypi/pico-sdk#3225 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
AXERA-TECH/ax-llm#81 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
zudochkin/awesome-newsletters#367 ·
-
bug help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
qmk/qmk_firmware#26492 ·
Los mantenedores suelen responder en 1 día