On 27.06.22 03:12, Edward O'Callaghan wrote:
It is probably a good idea to create two branches but probably more for the sake of very old hardware not so easily accessible, par masters springs most to mind. Exceedingly old Intel/VIA could also be included although I am not sure which year to pick as the line in the sand there for 'old'?
Why pick an arbitrary year at all? IMHO, if it ever comes to this, we should use existing lines, like what hardware interface they use.
Also, what's your experience with the code for Intel/VIA? where is it causing trouble?
Specifically to freeze them on a branch and let them live out the rest of their life?
They all benefit from the current and future layout work, for instance. Especially Intel devices since ~2009 with the IME. I don't see how to freeze that. All the documentation in the world about flashrom would have to make exceptions, e.g. "if you use legacy flashrom, you need to do this instead...". That alone seems much more effort than keeping a few lines of code around.
The key motivation for two branches would be to allow flashrom as a project in terms of core logic (driver API / remove global state / etc) to progress forwards with well supported (tested) hardware that we can maintain. That means, essentially, removing the fear of breaking exceptional old hardware drivers that the majority of active contributors do not have the means to test with practically speaking.
It's all open source, you know. There is a simple way to test any patch: reading and reasoning. You make me believe that people are actually afraid to read and understand the existing code that could break.
Regarding the claim;
The reoccurring idea to remove problematic code mostly targets programmer drivers that are not tested. For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google. Sometimes the code wasn't even working when it was merged.
This is a bit hyperbole, the only known case of this I am aware of in the current environment was the ene*/mec* and this was dealt with already.
Sorry for rounding incorrectly. 2 out of 5 then?
Unit-tests written for this and the maintenance burden came from Google anyway.
WDYM?
I can say the older EC paths for ChromeOS were extremely undocumented [I couldn't even find out if we were meant to be supporting them or not!] when I began deforking flashrom so the ene*/mec* situtation misstep was a unfortant mistake of trying to do the right thing by giving community open support to our hardware with a team of only half a person at the time. Mistakes were owned and rectified, however the lesson was learnt - for example no one is pushing cros_ec in the ChromiumOS tree upstream as it is clearly not suitable [code quality, no tests, no documentation and too many layering violations due to EC state management].
Why not fix it then? I think a driver for CrOS ECs would be very useful.
Nico