[flashrom] CrOS flashrom compatibility and upstreaming of CrOS features

[Nico Huber]

Hi David,

sorry for taking that long. I guess I was waiting for more people to
chime in (I'll still not abandon that hope, generally).

On 25.01.2018 08:12, David Hendricks wrote:
> On Wed, Jan 24, 2018 at 10:36 AM, Nico Huber <nico.h at gmx.de> wrote:
> 
>> Hey folks,
>>
>> during review of commits that port per-region file arguments [1] from
>> CrOS flashrom over here, we ran into a discussion about the command line
>> interface changes. The basic question that arose is
>>
>>     Do we want to maintain full CLI compatibility to CrOS flashrom?
>>
>> This would have the upside, that it would ease remerging of the two
>> flashrom versions (in some unknown future). And anybody currently
>> using CrOS flashrom could transition more smoothly. OTOH, depending on
>> how the compatibility is achieved, it might increase the costs for
>> review and development heavily (for a project with 0 spare resources).
>>
>> To not have to discuss this each and every time when some non-trivial
>> feature is ported over from CrOS, I'd like to have some opinions, how
>> valuable CLI compatibility is to you all and how we want to achieve it.
>> I have currently some alternative ideas in mind that I'll sketch below.
>> Feel free to add other ideas or just to comment them.
>>
> 
> Option #2 seems pretty good IMHO. I suspect that CrOS will need to maintain
> their legacy behavior for a while longer, but that does not need to hold
> back upstream. We should of course improve our testing to avoid breaking
> one or the other, at least without sufficient reason and time to adjust.

Sounds good to me. Though for testing, we'd have to implement the CrOS
compatible CLI rather sooner than later.

> 
> Some background on this: CrOS currently maintains a separate CLI in their
> tree, cli_mfg.c, specifically because the upstream CLI was not well-suited
> for their manufacturing needs. Things like syntax changes, additional
> options, verbosity, error handling, etc. were simply different from what
> typical users expect. The partial read/write/verify syntax was developed to
> meet specific needs of the manufacturing flow, and the write-protection
> syntax was added specifically to address the way write-protection works on
> Chromebooks. Stuff like "combining multiple files" was done to avoid
> wasting valuable time on the assembly line and at runtime during normal OS
> maintenance (yes, seconds really do matter).

Hmmm, that valuable-time requirement is really something that would
suffer with a wrapper script. So let's try to keep compatibility inter-
nally.

> 
> I'd still like to see CrOS converge with upstream so we share development
> and testing efforts. It would also be great to have more device
> manufacturers working with upstream. Having an alternate CLI coexist
> alongside the "classic" CLI seems like a decent compromise IMO. Both sides
> will benefit from a converged codebase, let's not make the CLI a blocking
> issue.

Agreed. Though, convergence will need effort on both sides...

Nico