# 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](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](https://review.coreboot.org…
* 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](https://review.coreboot.org…
* clang-format:
[https://review.coreboot.org/c/flashrom/+/38673](https://review.coreboot.org…
* 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/](https://www.getzola.org/)
also,
*
[https://jaspervdj.be/hakyll/](https://jaspervdj.be/hakyll/) is
fantastic.
* Check out
[https://jamstack.org/generators/](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:Copy…
) for details). Do not submit copyrighted work without permission!”
