[coreboot] [PATCH] flashrom: Support only one operation at a time

[Richard Smith]

Carl-Daniel Hailfinger wrote:

> Well, since
> 1. OFW uses its own flasher, so it won't benefit from libflashrom
> 2. any emergency flasher in coreboot needs to be small (a one-chip-only
> solution) and flashrom is 114k stripped
> I don't see any benefit in libflashrom.

Its only a benefit if you see value in having multiple front ends if 
flashrom is flexable enough that its the the only user interface then 
libflashrom dosen't help you much.

The goal of a libflashrom would be so that commercial 
manufacturers/hobbyist makers of device programmers have a nice clean 
way of using the underlying flashrom plumbing for whatever user 
interface they want to provide.

>> (is the cheetah stuff at a testable level yet?)
> 
> I concentrated on FT4232H support for now. Both Cheetah and FT4232H have
> one big problem: Compilation and linking. Do we link against libftdi or
> not?W ill symbol resolution be done by the linker automatically or do we
> use dlopen() and dlsym()? Should we use compile time flags instead? How
> should we modify our makefiles for that?
>

My vote would be for a compile time option including the ability to link 
static. The cheetah appears to make that difficult since they only 
provide an .so.  I don't think its too much to to make users who want to 
use flashrom with external support recompile with that support enabled.

>> I'm more thinking about the future where the feature set would grow
>> based on the features of a specific programmer or something that a
>> non-coreboot user would need.
> 
> I'd say we wait for such feature set extensions before trying to design
> an API. Most attempts in the past to create future-proof APIs were
> thwarted either by new features or crappy hardware...

This is what I mean about being serious about supporting external 
programmers.  Setting up the stage to become the "the" plumbing for open 
source programmers.  Perhaps thats too far outside of the coreboot scope 
but if thats the case then external programmer support will just be 
something that a few of us with specific needs are driving rather than 
something that can develop into a life of its own.

-- 
Richard A. Smith
smithbone at gmail.com