# 2nd June 2022, 6:00 - 7:00 am UTC+0
Attendees: Felix Singer, Chinmay Lonkar, Edward O’Callaghan, Joursoir, Anastasia Klimchuk, Nikolai Artemiev, Evan Benn, Aarya Chaumal, Thomas Heijligen, Arthur Heymans
## Decisions Summary
* We want to look into git hooks and build bot scripts which check the code style for compliance. Discussion thread will be opened on the mailing list. * We want to renew the flashrom website and we will look into static site generators. Discussion thread will be opened on the mailing list.
## Agenda
* [aklm] Welcome our students! * Aarya * Chinmay * Joursoir * [aklm] We have people from 3 software companies here, and also independent developers. This makes 4 parties, each one is using flashrom in their own ways, each one has some critical use cases. Can we talk and describe to each other how we use flashrom, what are critical use cases (unless it’s confidential)? My main goal is that we have more understanding (and maybe more patience) of each other’s work. * Servers: LinuxBoot, e.g. for updating CrOS-style `vpd` variables. This usually necessitates static binaries which are currently quite large (>1MB). Short of re-writing relevant bits of Flashrom (e.g. in Go), is there a good way to shrink the flashrom binary size? Some users are compiling with musl, for example: [https://github.com/flashrom/flashrom/pull/155%5D(https://github.com/flashrom...) * How to make binary smaller * [quasisec] * Convert flash chips. C into parseable database * Make more parts of flashrom as re-usable units - i.e., modularity, remove globals etc. * Reduce binary size via build system changes * Removing globals plays into this, it adds more modularity * Edward: Chrome OS uses flashrom to update EC and AP. There are few other components that are updated with flashrom. We go through the internal path. Main programmers are ichspi, sb600spi, linux_mtd. * Thomas: (from Simon) Making things with FPGA , nothing to do with coreboot. Completely writing the whole flash chips. * Flashrom is Swiss army knife * Thomas (Secunet) : Development of coreboot, external programmer to read/write chip. Internal programmer for spi. libflashrom on the payload base. * [FelixS] coreboot uses a git-hook to run clang-format stylecheck. Should we use it too? * [https://review.coreboot.org/c/flashrom/+/43602%5D(https://review.coreboot.or...) * The script aborts the creation of a commit if the changed code doesn’t comply with the style guidelines. * We need to add make target * Is the check-style script blocking? What if false-positives appear? * Maybe another target on the build bot? Comments are added into Gerrit patch. * Script will run on git commit, locally * Arthur: I tried to make coreboot tree consistent, but clang choked on this, had a runtime. ~1 month ago I was trying this. * Thomas : data structures can be hard to format, like flashchip.c * We can put exceptions in the tool, so that formatting is not touched. * Arthur: We can just try, have a play with it and maybe it works in the tree? * It is hard to configure for parts of file, usually whole file or nothing. * First step can be a page on the build bot, which is not blocking. Second step adding comments to gerrit. * The patch will install a hook with make, meson is not adding a hook at the moment. * TODO start a topic on the mailing list * [FelixS] Should we use a tool for code formatting? * uncrustify: [https://review.coreboot.org/c/flashrom/+/42556%5D(https://review.coreboot.or...) * clang-format: [https://review.coreboot.org/c/flashrom/+/38673%5D(https://review.coreboot.or...) * Arthur: Uncrisfity works on coreboot * quasisec@: I one word: Yes. * quasisec@: Actually we can go beyond syntax checking and perhaps add: * Scan-build as a buildbot target to check for possible bugs (overflows etc) * Also coccinelle semantic patching for common bad or good patterns that should be applied. https://www.kernel.org/doc/html/v4.14/dev-tools/coccinelle.html * [FelixS] Should we rework / rebuild / modernize the flashrom.org website? * The flashrom website looks like a site from the early 2000’s. That’s not very attractive for potential interested people. The site should be replaced with something which looks modern. * quasisec@ needs more shiny! :D * Static site generators are easy to manage, they reduce maintenance burden (e.g. less or no updates) and also the risk for server-side security issues. * quasisec@ +1, also easy for the community to check in changes under review. All just markdown. * FelixS: More democratic to make changes for the wider community. * quasisec@ suggestions: * [https://www.getzola.org/%5D(https://www.getzola.org/) also, * [https://jaspervdj.be/hakyll/%5D(https://jaspervdj.be/hakyll/) is fantastic. * Check out [https://jamstack.org/generators/%5D(https://jamstack.org/generators/) * Furthermore, it makes hooking up Doxygen code documentation generation trivial. * We have to find out what we need and which framework supports what. Then, various frameworks need to be evaluated and we need a plan on how to migrate to the new site. * [aklm] how do we build a knowledge base for users? Ideally such that users can update content themselves? * TODO start thread on mailing list * aklm: Wiki has 33 users, but wiki is rarely updated * Chinmay: There is a tool docsify. Lots of themes, or you can make your own theme. I can show an example? Yes! * Thomas: we need to make a list of requirements * There is some C code which generates wiki markdown with the list of chips. It needs to be run manually. It can be run on buildbot. * Mediawiki edit page says “Please note that all contributions to flashrom may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here. You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see [flashrom:Copyrights](https://www.flashrom.org/index.php?title=flashrom:Copyrights&action=edit... ) for details). Do not submit copyrighted work without permission!”