Libflashrom: Difference between revisions

From flashrom
Jump to navigation Jump to search
m (→‎TODO: libtool)
Line 89: Line 89:
* pkg-config support would be nice, i.e., some simple '''libflashrom.pc''' file.
* pkg-config support would be nice, i.e., some simple '''libflashrom.pc''' file.
* It should be evaluated if it makes sense to use libtool (it probably does) to get a well-tested and portable shared library handling (only "manual" libtool, no autoconf/automake).
* It should be evaluated if it makes sense to use libtool (it probably does) to get a well-tested and portable shared library handling (only "manual" libtool, no autoconf/automake).
* The public API should not use C99 features, as that makes it hard or even impossible to use the lib from C++ code (e.g. via a Qt-based GUI) or to make a C++ wrapper lib. Specifically '''.name = "foo"''' syntax is problematic for example (in the public API, doesn't matter if used elsewhere).
* Making Python- or Ruby-bindings at some point is also interesting and feasible once libflashrom is sufficiently usable.

Revision as of 07:56, 14 July 2011

libflashrom is a shared library which can be used to write programs which need to detect/read/write/erase flash ROM chips using various programmers.

It is, among other things, useful so that different frontends can be written (a command-line tool, various GUIs, libpayload integration, others).

Status

Work in progress.

Building

$ make libflashrom.a

API

The following sections describe how a libflashrom API could look like. This is just a first attempt, it's not yet finished and not yet implemented. Comments welcome.

General

fl_init() Initialize libflashrom.

fl_shutdown() Shut down libflashrom, close devices or files, free all resources, etc.

fl_set_loglevel() Set the loglevel which libflashrom should use to output errors/warnings/info/debug messages. Valid loglevels: TODO.

fl_set_log_callback() Set a callback function which will be invoked whenever libflashrom wants to output messages. This allows frontends to do whatever they see fit with such messages, e.g. write them to syslog, or to file, or print them in a GUI window, etc.

Querying

fl_version() Return one or more version items of libflashrom, e.g. the lib major/minor/micro version number, the svn revision, or similar.

fl_sysinfo() Return some information about the (build- and host-) system, which libflashrom knows about, e.g. gcc version used, libpci version, uname, etc.

fl_supported_programmers() Get a list of supported programmers.

fl_supported_chips() Get a list of supported flash ROM chips.

fl_supported_boards() Get a list of supported mainboards.

fl_supported_chipsets() Get a list of supported chipsets.

Programmers

fl_programmer_init() Initialize the specified programmer.

fl_programmer_shutdown() Shut down the specified programmer.

fl_programmer_capabilities() Get the capabilities of the specified programmer. Valid capabilities: TODO.

Operations

fl_image_read() Read the current image from the specified ROM chip.

fl_image_write() Write the specified image to the specified ROM chip.

fl_image_erase() Erase the specified ROM chip.

fl_image_verify() Verify if the specified image is the same as the contents of the specified ROM chip.

Other

...

TODO

This is a random list of TODO items which need to be fixed in order to make a usable and useful libflashrom.

  • There should be one single flashrom.h or libflashrom.h include file, which contains (only!) the function prototypes and macros which belong to the public libflashrom API.
  • All functions and macros of the public API should have a prefix in order to not pollute the namespace of the programs that link against libflashrom.
    • Suggestion: fl_ and FL_. Examples: fl_init() or FL_ERR_MALLOC.
  • No function in libflashrom is allowed to call exit().
  • All public API functions should return meaningful and unique error codes (which should have useful macros/names such as FL_OK, FL_ERR_MALLOC, etc.).
  • pkg-config support would be nice, i.e., some simple libflashrom.pc file.
  • It should be evaluated if it makes sense to use libtool (it probably does) to get a well-tested and portable shared library handling (only "manual" libtool, no autoconf/automake).
  • The public API should not use C99 features, as that makes it hard or even impossible to use the lib from C++ code (e.g. via a Qt-based GUI) or to make a C++ wrapper lib. Specifically .name = "foo" syntax is problematic for example (in the public API, doesn't matter if used elsewhere).
  • Making Python- or Ruby-bindings at some point is also interesting and feasible once libflashrom is sufficiently usable.