diff options
author | Julius Werner <jwerner@chromium.org> | 2016-05-12 14:40:57 -0700 |
---|---|---|
committer | Julius Werner <jwerner@chromium.org> | 2016-05-17 22:48:28 +0200 |
commit | 2296479dfd886d4cf4c145f1d3ed1ec64dc20630 (patch) | |
tree | 15b93696b4470064fb080efcbc04a260bddb8129 /Documentation/Doxyfile.coreboot | |
parent | 4bab6e79b078c76d0a42883c4b4c9c68615d5a1e (diff) |
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses
The libpayload CBFS APIs are pretty old and clunky, primarily because of
the way the cbfs_media struct may or may not be passed in and may be
initialized inside the API calls in a way that cannot be passed back out
again. Due to this, the only real CBFS access function we have always
reads a whole file with all metadata, and everything else has to build
on top of that. This makes certain tasks like reading just a file
attribute very inefficient on non-memory-mapped platforms (because you
always have to map the whole file).
This patch isn't going to fix the world, but will allow a bit more
flexibility by bolting a new API on top which uses a struct cbfs_handle
to represent a found but not yet read file. A cbfs_handle contains a
copy of the cbfs_media needed to read the file, so it can be kept and
passed around to read individual parts of it after the initial lookup.
The existing (non-media) legacy API is retained for backwards
compatibility, as is cbfs_file_get_contents() (which is most likely what
more recent payloads would have used, and also a good convenience
wrapper for the most simple use case), but they are now implemented on
top of the new API.
TEST=Booted Oak, made sure that firmware screens and software sync
worked okay.
Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14810
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Diffstat (limited to 'Documentation/Doxyfile.coreboot')
0 files changed, 0 insertions, 0 deletions