# 2024-06-12 - coreboot Leadership Meeting
## Attendees
Werner Zeh, Matt DeVillier, David Hendricks, Mina Asante, Jonathan Hall, Martin
Roth, Felix Singer,
Felix Held, Nico Huber, Jay Talbott, Rhys Perry, Karthik Ramasubramanian,
Shelley Chen, Nicholas
Chin, Ron Minnich, Mike Banon, Julius Werner, Marshall Dawson.
## Announcements & Events
* FOSSY conference: August 1-4 2024 in Portland, Oregon, USA
https://sfconservancy.org/fossy
* COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04
https://coscup.org/2024/en/landing
* OSFC will be in Bochum Germany - September 3-5
https://www.osfc.io
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
## Open Action Items
* 2024-05-01
* Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to
translate to Russian (?)
* 2024-03-20
* Martin:To Add a note to the gerrit guidelines to email the leadership for
further discussion and
guidance when code submissions are not up to standard.
* 2024-03-06
* Martin: To update gerrit contributing guidelines documentation.
(https://doc.coreboot.org/contributing/index.html)
* 2024-01-10
* Nico: [https://review.coreboot.org/q/topic:enforce_region_api]
* Daniel: Look at how we want to localize (non console) strings for
coreboot. Long term project.
## Minutes
### [Felix S/Martin] We’ve got a OSFF booth accepted for [FOSSY
conference](https://sfconservancy.org/fossy)
* 1st - 4th August
* Looking for volunteers to help with the booth.
* Please reach out to FelixS or Martin if you’re interested. We might be able
to help out some with
travel or hotel costs.
### [Martin] Infrastructure
* We need additional people to help with coreboot infra.
* Using NixOS for the base OS
* Docker images for gerrit, jenkins, other services.
* Reach out to coreboot leadership if interested.
* Felix will be the infra lead, but if we can’t find people in the community,
we may need to hire
someone (some company) to help with this.
* Obviously this will cost the project cash
* [MattD] We need a backstop, even if we have volunteers, so hiring a
company would probably be good anyway.
* If any or our contract companies have recommendations, please suggest
good companies.
### [Elyes] Add lint rule to avoid duplicated includes.
* I’ve added some lint rules to warn when a header is duplicated through
another header which is supposed to provide it.
(see [https://review.coreboot.org/c/coreboot/+/81907]) The rules I’ve used
are those in:
``Documentation/contributing/coding_style.md``
As per Nico’s comments, we need some rules (if this is something we want
to do.)
* Headers can still be included in other header files.
* [Martin]: This is (or should be) just enforcing what’s already documented
in the coding style document.
If this is a bad idea, let’s remove it from the coding style and not have a
conflict
between what we’re willing to enforce and the coding style guide.
* [Nico]: This could make updating headers more difficult.
* [Ron]: This seems like a slippery slope - do we want to alphabetize the
header list? Christmas tree header list.
* Those aren’t how we do things here. No required alphabetization or other
styles for headers.
* [David]: IWYU may make things fragile. Good in theory, if it's easy and
reliable to use/enforce
then we should do it.
* [Julius]: The coding style wastes reviewers time. Do we really need to
worry about this?
* [Martin]: This patch would fix that.
* [Nico]: Do we want to just prohibit bulk cleanups?
* [Martin]: Does that mean we should get rid of the coding style? If we’re
not going to enforce it, why have it?
* [Nico]: it’s good for new users.
* [FelixS]: could IWYU be used instead of self-written scripts to supply
suggestions?
* [David]: Maybe we should roll this out slowly before enforcing it.
Hopefully this won’t introduce a bunch of Diffs.
* The work is already done, so let’s prevent new style violations from
going in.
* [Martin]: Can we agree that we can submit this and if it causes issues we
can roll it back?
* [David]: We shouldn’t block it unless we can articulate exactly why it’s
a problem. Let’s think
about it for a week and if there aren’t any explicit issues, then let’s merge
it.
### [Yidi Lin] [Do we consider GPIO ball names definitions in <soc/gpio.h> as
part of
<gpio.h>](https://review.coreboot.org/c/coreboot/+/82813/1/src/mainboard/google/kukui/gpio.h)
?
* This is related to the above header issue.
* Listed in the style guide as an example
* [Nico]: These two gpio headers aren’t really the same thing. One is
hardware, the other is the general function headers.
* [Matt]: Does the main GPIO.h automatically include soc/gpio.h?
* Felix: Yes, and includes the IWYU annotation that it should be supplied.
* [Matt]: As long as we’re being consistent across the codebase, it should be
fine. It looks like
we’re normally including soc/gpio.h in mainboards. There are currently 364
instances of that - so
let’s not change it to comply with the style guide. Let’s update the style
guide and update the
patch.
* [Julius]: Let’s just leave things as they are and not do bulk updates.
* [Jonathan]: This seems like a misinterpretation of the style guide - it’s
saying that you don’t
need to include both. It doesn’t seem to say that you should use gpio.h
instead. Let’s edit the style guide to clarify this.
* **Decision**: Let’s just edit the style guide for clarity and not force
inclusion. That means
that we’d drop these patches (unless the board owner prefers it.)
### [Felix H] Usage of LLM outputs making the commit messages bad
* I’ve seen commit messages (patchset 2 of 82871, 82872) that look very much
like output from some
LLM that say little in much text and I’d very much prefer that we keep commit
messages concise, so
I’d like to discuss if we want to allow usage of LLM output and if so how we
should make sure to
mainly get possible advantages of that but keep the disadvantages to a minimum
* [Martin] Yes, I think we want to allow the output from LLMs in patch
descriptions, in fact I was
just talking about creating some automation to generate a description of the
patch that could be
(optionally) used to update the commit message. People who are less fluent in
English could really
benefit from this.
* [Martin]: Let’s just say that commit messages should be concise and related
to the patch.
### [Karthik] RFC - Extend Coreboot FileSystem to disk
* [Extend CBFS to Storage
Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tUN5bLR2ciOvw)
Look at the document for reasoning. Please review it and make comments.
* [Martin]: I kind of hate the idea of loading firmware from the drive for
stages before the
payload - this feels like a slippery slope and that next we’re going to need
network drivers in
coreboot to support loading the firmware over the network. Payload can do what
it wants.
* [David]: This sort of thing is pretty normal in the non-x86 world.
* [Werner]: The mass storage device is really owned by the OS. If the
firmware is on the drive, we
could break the boot when the drive is formatted or replaced.
* [Karthik]: only boot critical components would be moved to the disk.
* [Martin/Felix]: This seems like a large security hole - your system can
be owned from the boot firmware instead of just the OS.
* [Julius]: This is just extending cbfs to the disk and not a part of an OS
file system. This is
mainly intended for CSME update. This would be only Ramstage or later and would
be optional.
* [Werner]: Requires adding mass storage devices. Allows coreboot to read
the entire disk. How does that affect security?
* [David]: Let’s assume that Google didn't screw up their implementation,
and focus on how this
would fit into upstream or if it should be blocked. It seems like it could be
an advantage for cost
savings (as Julius points out) by making it so laptop vendors don't need a huge
flash chip for things like CSME binaries.
* [Martin]: This needs further discussion, so please review the document
and make comments there.
In general I feel like if something is needed by some coreboot users, we should
try to be accepting
of their needs (assuming that it’s not adding additional binary blobs.
# Next Leadership Meeting
* June 26,2024.
* [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 minutes
*[2024-06-12](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p1).
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
