# 2026-01-21 - coreboot Leadership Meetings
## Open Action Items
* 2024-11-27
* [Open] Send out poll with regards to LLM usage (requested by SFC)
* 2024-10-30
* [Open] Add clarification to docs: “Do not use gerrit change-id or CB:
format in reference to already-merged patches.”
* 2024-10-16
* [Open] Matt: Set up a meeting to discuss board status alternatives and
send out invites.
* Decouple data collection with uploading
* Require gerrit credentials or other auth to push
* Json format?
* https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh
* 2024-09-18
* [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects
and action plan.
* Werner: Send out an invite for the meeting.
Sent out a poll to find a time slot:
https://rallly.co/invite/1c8J3azXAcje
* 2024-05-01
* [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like
to translate to Russian (?).
* 2024-01-10
* Nico: (https://review.coreboot.org/q/topic:enforce_region_api)
* [Open] Daniel: Look at how we want to localize (non-console) strings
for coreboot. Long-term project.
## Announcements & Events
* FOSDEM 26
Date: January 31 - February 01
## Late GMT coreboot Leadership Meeting Minutes
## Attendees
Martin Roth, Werner Zeh, Alicja Michalska, Matt DeVillier, Mina Asante, Karthik
R, Jeremy Compostella, David Hendricks.
## Minutes
### Discuss the early meeting agenda
### [MartinR] Rust in coreboot
* We’ve discussed it in the past, but rust is making significant inroads in
firmware and OS programming. Is it time to start allowing rust code in coreboot?
I’ve developed a proof-of-concept for coreboot that adds rust to the
coreboot toolchain and adds support to the build.
* [Max] Where would we use it? It seems you mean to add rust code into core
coreboot code. If yes, then I don’t really know how to accomplish that. For the
Linux kernel its “easy” because many drivers can be build as modules and are
therefore separate entities. So you can write new drivers in rust (provided
some bindings to the c code). For coreboot it is more difficult. We basically
only have bootblock, romstage, ramstage, libpayload and SMM rmodule.
Reimplementing any of these is not going to happen. Its too much work and too
error prone, because you would need to replace it in one go. SMM module may be
the exception here, because its security sensitive and not as big as the other
ones. If you want to have c code and another programming language side by side
in the same compilation unit, then rust is in my opinion a bad choice (as is
almost any other language). The only language I know that has really good c
interoperability is zig. Zig can actually compile your C code and zig code
together. So in summary I think that the SMM module is the only thing that may
make sense to replace with rust code.
* [Alicja] The rust C bindings seem to be frequently broken
* [Werner] It does seem like this is how the firmware community is going,
so it might be good to get ahead of it.
* [Martin] OpenSIL is looking at using rust, but that’d still be years
away. openSFI is also looking at allowing rust.
* [DavidH] What about building payloads with the coreboot toolchain? If we
support rust, we can build payloads that need rust. Patina UEFI would be an
example - it’s written in rust.
* [Martin] Currently my patch (which I haven’t had time to push) uses
rustup, a toolchain manager, but we can also use LLVM.
* [Karthik] When we do use rust, it’d be good to make sure that we don’t
use UNSAFE all over the codebase. Let’s make sure we do good reviews.
### [MartinR] OpenSFI
* OCP is working to develop openSFI, a unified interface between FSP and
openSIL The current targets are EDK2 and coreboot. It would be good to have
more coreboot involvement and representation at the meetings:
(https://github.com/opencomputeproject/OpenSystemFirmware/wiki/Open-Silicon-Firmware-Interface)
* This project meets every other week on Thursday from 9-10 AM Pacific
time.
Meeting details will be in the coreboot calendar.
## coreboot Leadership Meeting - Early GMT
## Attendees
Mina Asante, Werner Zeh, Ziang Wang.
## Minutes
### [Ziang] Considering pausing the early meeting
* Hey guys, I hate to raise it, but the early meeting has not gained a topic
for a long while, plus AFAIK some companies in Asia are shifting interest from
coreboot (like Intel, Asia-Pacific, layoffs are still going on…). AMD might
come back though, they started the OpenSFI stuff mentioned by Martin, but the
time is not determined. So for the time being, we are probably the only entity
in Asia that needs to use this time slot, which would be unnecessary. For
anything that matters, we could make it to the late meeting.
* Decision: Temporarily Cancel the Early GMT leadership meetings.
# Next Leadership Meetings Date
* February 04, 2026.
* [coreboot Calendar](https://coreboot.org/calendar.html).
# Notice
Decisions shown here are not necessarily final and are based
on the current information available. If there are questions or comments
about decisions made, or additional information to present, please put
it on the leadership meeting agenda and show up if possible to discuss
it.
Of course items may also be discussed on the mailing list, but as it's
difficult to interpret tone over email, controversial topics frequently
do not have good progress in those discussions. For particularly
difficult issues, it may be best to try to schedule another meeting.
# coreboot Leadership Meeting Notes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
