---
datetime: 2022-06-30T10:00:00+01:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#monkey-business` voice channel
teams:
- community
participants:
- TODO
---
## Agenda
* Community summary
* Planning release 0.10 (July 25, 2022)
* Documentation requirements
* Projects / people updates
* ARM (RăzvanV, Michalis)
* Architecture-independent syscall shim (RăzvanV, RăzvanD)
* Binary compatibility (RăzvanD)
* ~~ARM virtual memory (Michalis)~~
* mmap (Marc)
* ukthread / Musl / clone (Simon, Dragoș, Aadhi, Florin)
* ~~synchronization / futexes (Adina)~~
* procfs (AndreiM)
* Firecracker support (AndreiT)
* VMware support (PaulU)
* Hyper-V support (PaulV)
* Randomness support (Sebastian)
* SMP for x86 (Marc, CristiV)
* ~~Profiling (Gabi, AlexP)~~
* ~~SSH server (AlexandraP)~~
* ~~Xen clone-based fuzzing (Radu)~~
* ~~Generic OS / unkernel fuzzing (Teo)~~
* ~~Memory randomization / deduplication (Terry)~~
* ~~Javascript support (AlexA)~~
* ~~Rust support (Vlad, Dennis)~~
* Synchronization (Sairaj)
* ~~SGX support (Xiangy)~~
* ~~Shadow stack (Maria)~~
* kraft / runu / kraftkit (AlexJ)
* Others
## Discussions
### Community summary
Hackathon at Aachen the previous week-end.
Good engagement from participants.
Future hackathons planned to take place in Munich, Karlsruhe and Manchester
USoC'22 planned to take place August 29 - September 10, 2022
Romania commuity gathering in late September
Should we keep the community meeting on Thursdays, 10am CEST, during the summer?
We want to get more people in leadership / ownership roles in the community: docs, CI/CD, PR management, release management, issue / task management, event organizing
### Planning release 0.10
Very quick tour of PRs for release 0.10: https://github.com/unikraft/unikraft/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22v0.10.0+%28Phoebe%29%22
### Documentation requirements
Discuss what documentation items should be part of the documentation website / repo (https://unikraft.org/docs/ / https://github.com/unikraft/docs)
TODO
### Projects / people updates
**ARM**
RV: Fix updates from MR, planning to do this around this weekend. Has dependencies before full merge to occur;
MR: Just a few cleanups and removing warnings;
**Architecture-independent syscall shim**
RV: Should be discussed in the maintainers meeting (11 July) -- should be discussed with Simon.
RV: To be discussed on Discord. Build system is working but some fixes required.
SK: On registration: a second provided system call list ("option syscall") so as to build different behaviour for the shim, so for optional syscalls can be dropped. On actual list, you get a real error and then the fix can be made. Just the `Makefile.uk` registration should be updated -- it's trivial. Will provide a patch for RV.
**Binary compatibility**
RD: Repository for binary compatible `static-pie` apps: https://github.com/unikraft/static-pie-apps
Support scripts / infrastructure: https://github.com/unikraft/app-elfloader/tree/lyon-hackathon, https://github.com/unikraft/run-app-elfloader
Work towards integrating helloworld features for multiple programming langauges.
In the next days will provide support for frameworks.
AJ/SK: To discuss in maintaiers meeting structure of the repo w.r.t. testing/uktest.
SK: To be worried about after 0.10 release.
**ARM virtual memory**
N/A.
**mmap**
MR: Large topic -- not just a syscall. What we have internally mmap/paging syscall which is pretty dirty. When we activate `posix-mmap` we split the mem in half: 50% to heap, 50% to `mmap` for anonymous mappings but it shouldn't work this way. The heap should grow dynamically, whenever `free` mem becomes available, it should be accessible by `mmap`. We have A/VADDR mappings and management. We need VMAs that create anonymous mappings which requires definition of mem structures so as to look up virtual address areas, e.g. "is it part of anonymous memory when a page fault occurs?" So the implementation is an interval / red-black tree so that we can make queries in the space with low `O()` complexity.
MR: Built a red-black tree header impelmentation which looks good. Next step is to map this structure to an interval tree so you can look it up with a key at a specific internval. After this, PR can be published.
MR: Next step is a lib to manage a virtual address space, doing options like splitting, merging, expanding virtual memory areas and always workring with the paging code and establishing relationship wit the virtual memory. How this is designed still needs thoughth. Goal is to have a generic Unikraft native library and then `posix-mmap` uses this native library which would also be used internally for other stuff. `posix-mmap` just offers the POSIX interface.
MR: For next releaase (v0.10), internal libs first.
**ukthread / Musl / clone**
SK: To wait for Razvan, Dragos is currently working on this. It's slowly becoming available. Next week the work begins. It's about integrating all the code from clone/musl and then finding out what's missing.
MR: Clean up for next release?
SK: Yes
MR: Clone1,2,3 is needed for the musl integration.
**procfs**
AM: Just finishing thesis which can provide new documentation. Need to have a call with RD about integration.
**SMP for x86**
MR: Main reason to not include the implementation is that all thei nterupt handling is based on the PIC chips. For new processors you use the APIC. Did research about this topic w.r.t. compatibility with KVM/natively and if it's the proper way to do. OSDevWiki tells us to disable the APIC. The intel manuals say it's ok (probably) to have both active. But need to investigate the IOAPIC, which needs to be configured as well which is connected to message signal interrupts (on the PCI side). So this is turning out to be a large topic which will touch a lot of the device code. Instead of changing all of this code, keep the code I have now with the parrallel APIC/PIC threads and keep the legacy PIC. Until the whole IO system is redesigned, we can make this change. Timeline for this is variable.
SK: This APIC stuff, is it increasing the interrupt number space? And the virtio
MR: Whe you use the X2 APIC, you have 256 IRQ vectors, vs. the 16 with the old PIC.
SK: Makes sense to get rid of PIC.
MR: For ARM we have the central controller part (GIC), they abstracted the interface with function pointers. Makes sense to use the same mechanics with interupt handling with a generic interface that works on all platforms to eventually call the "enable interrupt" function so you don't have to implement for everyr platform, you just have the drivers so you can ultimately have config options at compile time. Feels like a better solution/architecture and moves away from x86/ARM-specific code implementation.
**RISC-V**
EV: Networking is working, so is NGINX. PR is ready to be reviewed. When started working on this originally, the abstraction vnirtual memory part was not yet integrated, so would like to migrate to this new upstream interface.
**Synchronization**
AJ: Not surer if this [blog post PR](https://github.com/unikraft/docs/pull/77) is part of a series or a one-off, need to clarify with RD.
MR: Blog post should be a series actually.
MR: Mutex/semaphore implementation are done using atomic operations which disable interrupts. It seems that the featureset (upgrade, downgrade lock) seems good. Need to do a review with smaller details but overall looks good
**kraftkit**
AJ: Nearly complete with `ukpkg`; currently working on `ukpkg pull`. Once this is done, internal testing can occur and I can begin working on `ukbuild` which will be much more trivial since it's simply invoking Unikraft's build system.
**Off-topic**
SK: Checkpatch for docs repo. RD should look into this ;-)
## TODOs and Decisions
RD: Contact high quality contributors of Aachen hackathon.
RD: Integrate PRs from Aachen hackathon.
RD: Provide language support as binary compatibility applications.
RD: Move Google Drive projects as GitHub issues and project tasks.
RD: Kick-off organizing USoC'22.
RD: Kick-off organizing Romania community meeting.
RD: Plan for future hackathons.
core: Start discussion about leadership roles in the community