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.

 

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 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).

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).

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.

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