On Wed, Sep 29, 2021 at 9:57 AM Patrick Georgi pgeorgi@google.com wrote:
Am Mi., 29. Sept. 2021 um 16:43 Uhr schrieb Jack Rosenthal < jrosenth@google.com>:
Overall I think introducing Python to the build would provide net benefit, mainly from Kconfiglib, but could also find other good uses in e2e tests like Ricardo was working on. Most people's Linux distros ship with a Python interpreter too, so most developers would be unlikely to notice the extra dependency introduction.
This is assuming that all python environments are alike. Experience disagrees.
Kconfiglib only uses Python standard libraries, and works with both Python 3.3+ and 2.7. I think it'd be pretty hard to find a Python environment it didn't work with.
In terms of Kconfiglib, we have a lot to gain by switching away from the Linux C implementation of Kconfig, mainly the ~30kloc of C code that we've forked from the Linux tree and hacked in our own customizations (KCONFIG_NEGATIVES). With Kconfiglib, these customizations get turned into a miniature Python script https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main/util/autoheader.py that we use to handle our custom header format, and a stable API to work off of so that we can uprev Kconfiglib without needing to change our scripts.
The customizations are a set of patches with simple maintenance (as documented in https://review.coreboot.org/c/coreboot/+/57879).
This is true, but the maintenance burden could be even less.
Additionally, the last Kconfig uprev didn't go so well, at least from the Chrome OS perspective, we saw a build flake that sat around for a few weeks bothering people.
In terms of Kconfiglib's stability and track record: I think it has it
covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already without any issues at all.
This project deals in 20 year timelines. Zephyr is at 5.5 years, while depthcharge is used exclusively in a tightly controlled environment (and even there we had - and have - our share of pythonic problems).
IMO 5.5 years of stability is a pretty good point to start considering adopting a new technology. If we wait for 20 years of it, there'll be something better than Kconfiglib out there ;)
At a minimum, I think we should consider introducing Python on an optional
basis (i.e., the C Kconfig implementation only gets used if a Python interpreter is unavailable), but making it required would be even better.
That idea is... horrible. Instead of only bringing in the python dependency we'd also create an environmental dependency that can silently introduce behavioral differences.
This project has the ability of building bit-identical firmware images on hosts spanning all kinds of CPU register sizes, endianness and operating system families. If you ever heard of "hermetic builds" being a good idea: the trustworthiness of our build is stronger - and part of making that possible is being (relatively) careful with picking our dependencies.
Fair, require python then. Most people have it on their systems anyways.
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado