Skip to content

Commit a333655

Browse files
authored
Merge pull request bytecodealliance#9 from intel/master
Sync up with main repo
2 parents 3b9cc32 + a66f18e commit a333655

File tree

3 files changed

+61
-46
lines changed

3 files changed

+61
-46
lines changed

README.md

Lines changed: 55 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -2,14 +2,14 @@ WebAssembly Micro Runtime
22
=========================
33
WebAssembly Micro Runtime (WAMR) is a standalone WebAssembly (WASM) runtime designed for a small footprint. It includes:
44
- A WebAssembly (WASM) VM core
5-
- The supporting APIs for the WASM applications
5+
- The supporting API's for the WASM applications
66
- A mechanism for dynamic management of the WASM application
77

8-
Why should you use a WASM runtime out of your browser? There are a few points where this might be meaningful:
8+
Why should you use a WASM runtime out of your browser? There are a few points where this might be meaningful:
99
1. WASM is already an LLVM official backend target. That means WASM can run any programming languages which can be compiled to LLVM IR. It is a huge advantage compared to language bound runtimes like JS or Lua.
10-
2. WASM is an open standard and it is fast becoming supported by the whole web ecosystem.
10+
2. WASM is an open standard and it is fast becoming supported by the whole web ecosystem.
1111
3. WASM is designed to be very friendly for compiling to native binaries and gaining the native speed.
12-
4. It can potentially change the development practices. Imagine we can do both the WASM application development and validation in a browser, then just download the WASM binary code onto the target device.
12+
4. It can potentially change the development practices. Imagine we can do both the WASM application development and validation in a browser, then just download the WASM binary code onto the target device.
1313
5. WASM can work without garbage collection. It is designed to support execution determinics for the time sensitive requirement.
1414
6. Maintain the safety goals WASM has of providing a sandboxed execution environment for untrusted code. In addition, because WASM is a compilation target, this implies the benefit of being able to target both an execution and security profile that is consistent across popular high-level programming languages.
1515

@@ -18,8 +18,8 @@ Why should you use a WASM runtime out of your browser? There are a few points wh
1818
Current Features of WAMR
1919
=========================
2020
- WASM interpreter (AOT is planned)
21-
- Provides support for a subset of Lib.
22-
- Supports "side_module=1" EMCC compilation option
21+
- Provides support for a subset of Libc.
22+
- Supports "SIDE_MODULE=1" EMCC compilation option
2323
- Provides API's for embedding runtime into production software
2424
- Provides a mechanism for exporting native API's to WASM applications
2525
- Supports the programming of firmware apps in a large range of languages (C/C++/Java/Rust/Go/TypeScript etc.)
@@ -31,7 +31,7 @@ Current Features of WAMR
3131

3232
Architecture
3333
=========================
34-
The application manager component handles the packets that the platform receives from external sources through any communication buses such as a socket, serial port or PSI. A packet type can be either a request, response or an event. The app manager will serve the requests with URI "/applet" and call the runtime glue layer interfaces for installing/uninstalling the application. For other URI's, it will filter the resource registration table and route the request to the internal queue of the responsible application.
34+
The application manager component handles the packets that the platform receives from external sources through any communication buses such as a socket, serial port or SPI. A packet type can be either a request, a response or an event. The application manager will serve the requests with URI "/applet" and call the runtime glue layer interfaces for installing/uninstalling the application. For other URI's, it will filter the resource registration table and route the request to the internal queue of the responsible application.
3535

3636
- The WebAssembly runtime provides the execution environment for WASM applications.
3737

@@ -144,7 +144,7 @@ ninja run
144144

145145
Embed WAMR into software production
146146
=====================================
147-
WAMR can be built into a standalone executable which takes the WASM application file name as input, and then executes it. To use it in the embedded environment you should embed WAMR into your own software product. WASM provides a set of APIs for embedded code to load the WASM module, instantiate the module and invoke a WASM function from a native call.
147+
WAMR can be built into a standalone executable which takes the WASM application file name as input, and then executes it. To use it in the embedded environment you should embed WAMR into your own software product. WASM provides a set of API's for embedded code to load the WASM module, instantiate the module and invoke a WASM function from a native call.
148148

149149
<img src="./doc/pics/embed.PNG" width="60%" height="60%">
150150

@@ -174,7 +174,7 @@ A typical WAMR API usage is shown below (some return value checks are ignored):
174174
wasm_runtime_clear_exception(inst);
175175
}
176176
/* the return value is stored in argv[0] */
177-
printf(fib function return: %d\n, argv[0]);
177+
printf("fib function return: %d\n", argv[0]);
178178

179179
wasm_runtime_destory_exec_env(env);
180180
wasm_runtime_deinstantiate(inst);
@@ -194,10 +194,10 @@ In general, there are 3 classes of API's important for the WASM application:
194194
195195
Built-in application library
196196
---------------
197-
Built-in API's include Libc APIs, Base library and Extension library reference.
197+
Built-in API's include Libc API's, Base library and Extension library reference.
198198
199-
**Libc APIs**<br/>
200-
This is a minimal set of Libc APIs for memory allocation, string manipulation and printing. The header file is located at ```lib/app-libs/libc/lib_base.h```. The current supported API set is listed here:
199+
**Libc API's**<br/>
200+
This is a minimal set of Libc API's for memory allocation, string manipulation and printing. The header file is located at ```lib/app-libs/libc/lib_base.h```. The current supported API set is listed here:
201201
``` C
202202
void *malloc(size_t size);
203203
void *calloc(size_t n, size_t size);
@@ -218,25 +218,25 @@ char *strncpy(char *dest, const char *src, unsigned long n);
218218
```
219219

220220
**Base library**<br/>
221-
Basic support for communication, timers, etc is available. You can refer to the header file ```lib/app-libs/base/wasm_app.h``` which contains the definitions for request and response API's, event pub/sub APIs and timer APIs. Please note that these API's require the native implementations.
221+
Basic support for communication, timers, etc is available. You can refer to the header file ```lib/app-libs/base/wasm_app.h``` which contains the definitions for request and response API's, event pub/sub API's and timer API's. Please note that these API's require the native implementations.
222222
The API set is listed below:
223223
``` C
224224
typedef void(*request_handler_f)(request_t *) ;
225225
typedef void(*response_handler_f)(response_t *, void *) ;
226226

227-
// Request APIs
227+
// Request API's
228228
bool api_register_resource_handler(const char *url, request_handler_f);
229229
void api_send_request(request_t * request, response_handler_f response_handler, void * user_data);
230230
void api_response_send(response_t *response);
231231

232-
// event AP
232+
// Event API's
233233
bool api_publish_event(const char *url, int fmt, void *payload, int payload_len);
234234
bool api_subscribe_event(const char * url, request_handler_f handler);
235235

236236
struct user_timer;
237237
typedef struct user_timer * user_timer_t;
238238

239-
// Timer APIs
239+
// Timer API's
240240
user_timer_t api_timer_create(int interval, bool is_period, bool auto_start, void(*on_user_timer_update)(user_timer_t
241241
));
242242
void api_timer_cancel(user_timer_t timer);
@@ -286,10 +286,10 @@ Below is a sample of a library extension. All code invoked across WASM and nativ
286286

287287
<img src="./doc/pics/safe.PNG" width="100%" height="100%">
288288

289-
Exporting native API steps
289+
Steps for exporting native API
290290
==========================
291291

292-
WAMR implemented a framework for developers to export API's. Below is the procedure to expose the platform APIs in three steps:
292+
WAMR implemented a framework for developers to export API's. Below is the procedure to expose the platform API's in three steps:
293293

294294
**Step 1. Create a header file**<br/>
295295
Declare the API's for your WASM application source project to include.
@@ -306,7 +306,7 @@ static NativeSymbol extended_native_symbol_defs[] =
306306
#include "ext_lib_export.h"
307307
```
308308

309-
**Step 3. Register new APIs**<br/>
309+
**Step 3. Register new API's**<br/>
310310
Use the macro `EXPORT_WASM_API` and `EXPORT_WASM_API2` to add exported API's into the array of ```extended_native_symbol_defs```.
311311
The pre-defined MACRO `EXPORT_WASM_API` should be used to declare a function export:
312312
``` c
@@ -352,7 +352,7 @@ static NativeSymbol extended_native_symbol_defs[] =
352352

353353
Use extended library
354354
------------------------
355-
In the application source project, it will include the WAMR built-in APIs header file and platform extension header files. Assuming the board vendor extends the library which added an API called customized(), the WASM application would be like this:
355+
In the application source project, it will include the WAMR built-in API's header file and platform extension header files. Assuming the board vendor extends the library which added an API called customized(), the WASM application would be like this:
356356
``` C
357357
#include <stdio.h>
358358
#include "lib_export_dec.h" // provided by the platform vendor
@@ -382,8 +382,6 @@ Below is the reference implementation of the server application. It provides roo
382382
``` C
383383
void on_init()
384384
{
385-
/* register resource uri */
386-
init_resource_register();
387385
api_register_resource_handler("/room_temp", room_temp_handler);
388386
}
389387
@@ -424,35 +422,20 @@ One WASM application acts as the event publisher. It publishes events to notify
424422
Below is the reference implementation of the pub application. It utilizes a timer to repeatedly publish an overheat alert event to the subscriber applications. Then the subscriber applications receive the events immediately.
425423

426424
``` C
427-
void on_init(
428-
{
429-
api_subscribe_event ("alert/overheat", overheat_handler);
430-
}
431-
432-
void on_destroy()
433-
{
434-
}
435-
436-
void overheat_handler(request_t *event
437-
{
438-
printf(“Event: %s\n", event->url);
439-
}
440-
441425
/* Timer callback */
442426
void timer_update(user_timer_t timer
443427
{
444428
attr_container_t *event;
445-
printf("Timer update %d\n", num++);
446429

447430
event = attr_container_create("event");
448431
attr_container_set_string(&event,
449-
"warning",
450-
"temperature is over high");
432+
"warning",
433+
"temperature is over high");
451434

452435
api_publish_event("alert/overheat",
453-
FMT_ATTR_CONTAINER,
454-
event,
455-
attr_container_get_serialize_length(event));
436+
FMT_ATTR_CONTAINER,
437+
event,
438+
attr_container_get_serialize_length(event));
456439

457440
attr_container_destroy(event);
458441
}
@@ -462,7 +445,32 @@ void on_init()
462445
user_timer_t timer;
463446
timer = api_timer_create(1000, true, true, timer_update);
464447
}
448+
449+
void on_destroy()
450+
{
451+
}
452+
```
453+
454+
Below is the reference implementation of the sub application.
455+
``` C
456+
void overheat_handler(request_t *event)
457+
{
458+
printf("Event: %s\n", event->url);
459+
460+
if (event->payload != NULL && event->fmt == FMT_ATTR_CONTAINER)
461+
attr_container_dump((attr_container_t *) event->payload);
462+
}
463+
464+
void on_init(
465+
{
466+
api_subscribe_event ("alert/overheat", overheat_handler);
467+
}
468+
469+
void on_destroy()
470+
{
471+
}
465472
```
473+
**Note:** You can also subscribe this event from host side by using host tool. Please refer `samples/simple` project for deail usage.
466474

467475
Samples and demos
468476
=========================
@@ -496,6 +504,9 @@ The sample also provides the native Linux version of application without the run
496504
<img src="./doc/pics/vgl_linux.PNG">
497505

498506

499-
Submit issues and request
500-
=========================
507+
Submit issues and contact the maintainers
508+
=========================================
501509
[Click here to submit. Your feedback is always welcome!](https://github.com/intel/wasm-micro-runtime/issues/new)
510+
511+
512+
Contact the maintainers: [email protected]

samples/littlevgl/README.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,11 @@ Zephyr
5757
WASM VM and native extension method can be built into Zephyr, Then we can install wasm app into STM32.</br>
5858
- Build WASM VM into Zephyr system</br>
5959
a. clone zephyr source code</br>
60-
`git clone https://github.com/zephyrproject-rtos/zephyr.git`</br>
60+
Refer to Zephyr getting started.</br>
61+
https://docs.zephyrproject.org/latest/getting_started/index.html</br>
62+
`west init zephyrproject`</br>
63+
`cd zephyrproject`</br>
64+
`west update`</br>
6165
b. copy samples</br>
6266
`cd zephyr/samples/`</br>
6367
`cp -a <wamr_root>samples/littlevgl/vgl-wasm-runtime vgl-wasm-runtime`</br>

samples/simple/README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
Introduction
22
==============
3-
This project builds out both host tools running on the host side, an application running on the device side. The device application consists of iwasm, application library, application manager, timers and sensors support. The device runs on Linux OS and interacts with host tools.
3+
This project builds out both host tools running on the host side, and an application running on the device side. The device application consists of iwasm, application library, application manager, timers and sensors support. The device runs on Linux OS and interacts with host tools.
44

55
It demonstrates an end to end scenario, the wasm applications life cycle management and communication programming models.
66

0 commit comments

Comments
 (0)