[RFC] libflashrom design choices

[Carl-Daniel Hailfinger]

Hi,

since the request to turn flashrom into a library pops up from time to
time, we have to make sure the flashrom code doesn't have any nasty
surprises.

- We have to decide on a design for fatal errors after initalization is
over. Some code uses exit(1) for any fatal errors after init, but that
it not really a valid choice for a library. After all, the caller may
want to clean up some stuff outside libflashrom.
- Kill all uses of exit(1) inside init code. The programmer_init code
has proper error handling and the caller must check its return code. I
have a patch for this.
- Memory leaks. We didn't have to care because everything was freed
automatically upon exit. I have a patch for the leaks I found from a
cursory glance at the code.
- Global error variable?
- Grouping all global variables into a single struct to avoid namespace
pollution.
- Adding struct flashchip to every function or relying on a global variable.
- Thread safety?
- Which symbols (variables/functions) should be exported in the library
interface?
- Consistent prefix for exported functions (namespace pollution)?
- message level functions (print_debug/print_warn/print_err/print)
instead of printf and friends so the library user can decide how/if to
display these messages.

After all the stuff above is solved, we can think about librarizing
flashrom.
There are probably quite a few additional issues I didn't list above.
Comments are appreciated. Patches are welcome.

Regards,
Carl-Daniel

[ron minnich]

thread safety? What about flashrom requires threads?

ron

[Carl-Daniel Hailfinger]

On 16.09.2009 06:58, ron minnich wrote:
> thread safety? What about flashrom requires threads?

libflashrom being called from a multithreaded GUI app?

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> Hi,
>
> since the request to turn flashrom into a library pops up from time to
> time, we have to make sure the flashrom code doesn't have any nasty
> surprises.

[..]

- possibly a libpci abstraction, or libpci emulation in libpayload

Stefan

[Stefan Reinauer]

Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > Hi,
> >
> > since the request to turn flashrom into a library pops up from time to
> > time, we have to make sure the flashrom code doesn't have any nasty
> > surprises.
>
> [..]
> possibly a libpci abstraction, or libpci emulation in libpayload

- plus a simple way to disable all external flashers. They don't make
sense when ie. integrating flashrom into FILO.

Stefan

[Carl-Daniel Hailfinger]

On 16.09.2009 10:28, Stefan Reinauer wrote:
> Stefan Reinauer wrote:
> > Carl-Daniel Hailfinger wrote:
> > > since the request to turn flashrom into a library pops up from time to
> > > time, we have to make sure the flashrom code doesn't have any nasty
> > > surprises.
> >
> > [..]
> > possibly a libpci abstraction, or libpci emulation in libpayload

Definitely. Some people have also suggested to use libpciaccess instead
of libpci. Either way, we need to improve the abstraction.
> plus a simple way to disable all external flashers. They don't make
>
> sense when ie. integrating flashrom into FILO.

Patch for this is almost ready, doing some last tests.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 16.09.2009 10:28, Stefan Reinauer wrote:
> > Stefan Reinauer wrote:
> > > Carl-Daniel Hailfinger wrote:
> > > > since the request to turn flashrom into a library pops up from time to
> > > > time, we have to make sure the flashrom code doesn't have any nasty
> > > > surprises.
> > >
> > > [..]
> > > possibly a libpci abstraction, or libpci emulation in libpayload
>
> Definitely. Some people have also suggested to use libpciaccess instead
> of libpci. Either way, we need to improve the abstraction.

Doesn't look much easier to use than libpci... What's the benefit?

[Carl-Daniel Hailfinger]

On 16.09.2009 11:28, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > On 16.09.2009 10:28, Stefan Reinauer wrote:
> > > Stefan Reinauer wrote:
> > > > Carl-Daniel Hailfinger wrote:
> > > > > since the request to turn flashrom into a library pops up from time to
> > > > > time, we have to make sure the flashrom code doesn't have any nasty
> > > > > surprises.
> > > >
> > > > [..]
> > > > possibly a libpci abstraction, or libpci emulation in libpayload
> >
> > Definitely. Some people have also suggested to use libpciaccess instead
> > of libpci. Either way, we need to improve the abstraction.
>
> Doesn't look much easier to use than libpci... What's the benefit?

No idea. I think it was suggested on IRC by tmzt or idwer (don't
remember exactly) due to its apparent smaller codebase (easier porting).

Regards,
Carl-Daniel