---
title: "Maintainers, November 21, 2022"
tags: unikraft, maintainers
datetime: 2022-11-21T11:00:00+02:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#maintainers-voice` voice channel
teams:
- maintainers
participants:
- TODO
---

## :dart: Agenda

- SMP-safe allocation ( @michpappas#3745 ) - I would start with this, because the 2nd item is going to fill the meeting time
- coding conventions ( @Marc Rittinghaus#0587 , @michpappas#3745 ): we already have 21 pages: https://docs.google.com/document/d/1_iRkdBjQtnqOj798ZNr23OQTWQcXPdpDsnfBikm6Pcg/edit

## :closed_book: Discussions

### SMP-safe Allocation

SK: There is also the case for printing in SMP environments.

HL: [`snmalloc`](https://github.com/Microsoft/snmalloc) does everything we may want and we may just reuse it.

MR: I used `memalloc`, but the pool size was smaller.
I could configure it.

HL: I don't know for sure, but we could ask them.

SK: I imagine that we would integrate the `snmalloc` and update the upstream version (and update it).

SK: We still allocate a TLS even if on a single core or with threading disabled.

MR: What is the default way when you enable SMP with the default buddy allocator.
Partitioning is one way.
The alternative would be that we just add synchronization to basic `ukalloc` functions.
You allocate from the same pool, you don't have to partition.
When you use a more complicated allocator, you could give up the synchronization.

MP: Yes, initially I supposed we would not use synchronization, due to performance reasons.
But I think we can trade off between performance and synchronization.

SK: I like the idea of a configuration option to make it SMP-safe via synchronization.

SK: The default setup should be a default allocator and a scheduler that handles all the cores.

MR: It's a valid approach and would eliminate the synchronization problem.
But I guess that a shared allocator is what most people would expect.

SK: The question is whether we do the allocator implementation SMP-safe or we do it at API level.

HL: The allocator should be the best way.
A lot of allocators have SMP options.
Otherwise, it would complicate the API.

HL: If you are switching to a different allocator, it's because of performance, memory consumption.
Enabling the API locking would mess the performance.

HL: We could have segregated pools (no synchronization required).
Other approach is to use a lock.

HL: Something making me anxious is some allocators have a larger dependencies on other components.
And we could get into deadlocks.

MR: I think it makes sense to synchronize allocators we have internally.

MP: I think we need to add this to a task list.

SK: What we want to also add printing from multiple cores.

MP: I imagine the case of a simple console.

There are multiple tracks on SMP: allocation, printing, locking, schedulers.

### Coding Conventions

Codacy is static analysis tool.

AJ: It's running `cppcheck` under the hood.

SK: There are some items that need to be configured.

AJ: We can disable some of the checkes from AJ.

AJ: I think it is potentially possible to add some configuration.

MR: I think it's possible to add a list of authors.

MP: There are projects where people really care about the authors.

SK: The SPDX I wouldn't remove.

For newer files we would only the SPDX headers.

AJ: You still need a copyright message.

`2022 The Unikraft Authors. All rights reserved.`

HL: A thing I don't know about.
When you sign off, you are basically signing a DCO.

MP: It makes sense to hold our horses and ask companies that want to add

## :wrench: TODOs and Decisions

RD/SK: Open up the printing API to have the messages somewhere else.
And make it SMP-safe.

RD: Collect false positives.

SK/RD: Discuss how can fill the license / author headers