On 21.06.23 01:23, ron minnich wrote: > The approach in the last 24 years (of this unsustainable project :-) has > been to get several mainboards of a type, and, once we have them, try to > work out what code is truly common and what code is similar but not truly > common.
AFAICT, for the last 5~8 years, this has not been the case. > Code that is truly common can then be factored out into places such as > src/lib. Code then migrates out of specific mainboards and into common > spaces. This progression has happened many times. > > And, yes, no question, this is an activity that likely occurs less than it > should. Such is our industry. Saying our industry is like that is why our industry is like that. Many people don't try to optimize the process just because that's how the process has been, even when there are low-hanging fruits that could help. Felix H. has shown good examples [1] how to optimize the process for a silicon vendor. I don't see why that wouldn't be possible else- where. Quite interesting to see, how the diligence of one individual makes things possible that "our industry" can only dream of. > It is not possible to know, a priori, what those common pieces will be. So > we are left with this admittedly non-ideal situation. IMO, it is possible, when people talk about it. > There is the further risk (this has happened) that a seemingly harmless > change is discovered to break some board, 1.5 years later. This has > happened. To me. >From my point of view, this is an argument to not refactor later, but as early as possible. Ideally before board ports are merged, because then the known good state is the known maintainable state. Nico [1] https://www.osfc.io/2022/talks/exploring-approaches-to-add-firmware-support-for-new-socs-to-coreboot/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
