On Wed, Sep 29, 2021 at 9:57 AM Patrick Georgi <pgeo...@google.com> wrote:
> Am Mi., 29. Sept. 2021 um 16:43 Uhr schrieb Jack Rosenthal < > jrose...@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 > -- Jack Rosenthal (he/him/his) Software Engineer - Chrome OS Google Boulder jrose...@google.com I value feedback from others. Please feel free to contact me directly, or file it anonymously at go/jrosenth-feedback <https://goto.google.com/jrosenth-feedback>.
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
