Skip to content

Commit c633510

Browse files
authored
Add an agenda for the 03-26 meeting. (#248)
And add the notes for the 03-12 meeting.
1 parent 4d46981 commit c633510

File tree

3 files changed

+100
-0
lines changed

3 files changed

+100
-0
lines changed

meetings/2020/WASI-03-12.md

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,3 +35,51 @@ Installation is required, see the calendar invite.
3535
the I/O story as we contemplate new kinds of streams and messages.
3636

3737
## Meeting Notes
38+
39+
Attendees:
40+
41+
Dan Gohman
42+
Jan Falkin
43+
Mike Trinkala
44+
Lee Campbell
45+
Andrew Brown
46+
Ralph Squillace
47+
Johnnie Birch
48+
Benjamin Brittain
49+
Mark McCaskey
50+
51+
Meeting notes:
52+
53+
Crypto API now has its own repository:
54+
https://github.com/WebAssembly/WASI-crypto
55+
Let's talk about process and expectations.
56+
57+
Merging send/recv into write/read:
58+
https://github.com/WebAssembly/WASI/pull/240
59+
This is a complex proposal, but the intention is to simplify the I/O story as we contemplate new kinds of streams and messages.
60+
It’s difficult to comment because it’s a big and fairly abstract PR
61+
Prototype implementation would help people see how this works out in practice
62+
Impromptu questions:
63+
Is it ok to have ambient authorities for debugging facilities such as logging?
64+
BB, Lee: Yes, handles are good
65+
Making it ambient is a decrease in potential power of the system
66+
67+
Impromptu agenda item:
68+
69+
DG: Is it ok if we have ambient authorities producing handles if the handles themselves can’t be used to do any I/O?
70+
Sealed capabilities are a useful concept.
71+
Lee: Avoid ambient authorities.
72+
BB: Capabilities aren’t just security, they also allow compositional design patterns.
73+
Lee: eg. logging. Where does the log output go? If you make it a handle, now you can send different handles that represent different sinks.
74+
Logging for debugging vs logging for production, perhaps are not so different use cases.
75+
Lee: A really powerful feature would be to have move-only semantics for handles, so you can send an instance a handle and it can be sure it’s the only instance with access to it.
76+
DG: Reference types proposal doesn’t have move-only semantics, but it’s something to think about
77+
Lee: Reference-counting can lead to awkward edge cases where references are kept live, or have aliases, in surprising ways.
78+
In Fuchsia, fd’s are 64-bit numbers and not reused.
79+
WebAssembly/interface-types
80+
BB: Move semantics changes how I’d design WASI APIs
81+
Eg. capabilities for memory regions. What does it look like to transfer a handle for one of these to another instance?
82+
Lee: Let’s have a discussion on rights, what rights look like, do we have a handle hierarchy?
83+
WASI doesn’t predefine __unix__.
84+
RS: GIve people a new engine, and it’s an easier step for people to take to port to. Guide them to doing the thing they want to do. Think of this as a new target. Don’t roll in old metaphors.
85+
Lee: If something doesn’t build, then you know what you have to fix. If it builds but doesn’t work, now you have to debug it.

meetings/2020/WASI-03-26.md

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
![WASI logo](/WASI.png)
2+
3+
## Agenda for the March 26 video call of WASI Subgroup
4+
5+
- **Where**: zoom.us
6+
- **When**: March 26, 16:00-17:00 UTC
7+
- **Location**: *link on calendar invite*
8+
- **Contact**:
9+
- Name: Dan Gohman
10+
11+
12+
### Registration
13+
14+
None required if you've attended before. Email Dan Gohman to sign up if it's
15+
your first time. The meeting is open to CG members only.
16+
17+
## Logistics
18+
19+
The meeting will be on a zoom.us video conference.
20+
Installation is required, see the calendar invite.
21+
22+
## Agenda items
23+
24+
1. Opening, welcome and roll call
25+
1. Please help add your name to the meeting notes.
26+
1. Please help take notes.
27+
1. Thanks!
28+
1. Proposals and discussions
29+
1. WASI currently uses a POSIX-like `errno` enum, but that seems
30+
not well suited for less POSIX-like APIs:
31+
https://github.com/WebAssembly/WASI-crypto/pull/13#issuecomment-599324384
32+
Many systems have evolved to having a single error enum shared
33+
across the whole system. Is it ok if we don't aim for that?
34+
1. POSIX tries hard not to let syscalls cause segfaults, returning
35+
things like `EFAULT` instead. There may be some value in this for
36+
POSIX compatibility, but how valuable is this otherwise? Should
37+
other WASI APIs be allowed to trap?
38+
1. Evolving idea: wasi-sdk API for extra emulation:
39+
1. `-D_WASILIBC_EMULATED_MMAN`
40+
1. `-D_WASILIBC_EMULATED_PAUSE`
41+
1. `-D_WASILIBC_EMULATED_RAISE`
42+
1. ...
43+
1. `-D_WASILIBC_EMULATED_ALL` ?
44+
and
45+
1. `-lwasi-emulated-mman`
46+
1. `-lwasi-emulated-pause`
47+
1. `-lwasi-emulated-raise`
48+
1. ...
49+
1. `-lwasi-emulated-all` ?
50+
51+
## Meeting Notes

meetings/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,3 +26,4 @@ Meetings of the WASI Subgroup of the W3C WebAssembly Community Group (CG) follow
2626
* [WASI January 16th video call](2020/WASI-01-16.md)
2727
* [WASI February 27th video call](2020/WASI-02-27.md)
2828
* [WASI March 12th video call](2020/WASI-03-12.md)
29+
* [WASI March 26th video call](2020/WASI-03-26.md)

0 commit comments

Comments
 (0)