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