View Change
1 comment:
File src/lib/cbfs.c:
Patch Set #3, Line 209: cbfs_load
> but where does that allocator come from? […]
Decompressing from DMA memory is a very bad idea, though, so you'd have to pass two different allocators (one for the decompression scratch and one for the final area) and make sure it doesn't try to decompress in-place. I think this would quickly become way too complicated.
I would see the operation you're trying to do as a special case of cbfs_load() instead of cbfs_map() (because you're trying to put the file into a specific place). I would just design this in a way where your allocator can tell you how much total space it has remaining... let's say in the simplest case you have
void *allocator_start;
size_t used_bytes;
size_t total_bytes;
as your allocator state. Then, really, you can just use the existing APIs to do:
void *file_start = allocator_start + used_bytes;
size_t size = cbfs_load(filename, file_start, total_bytes - used_bytes);
if (!size)
...handle OOM error...
used_bytes += size;
and then you have your file loaded to where you want, automatic decompression included. If you want a more complicated allocator (e.g. one that keeps enough state to be able to free the allocation later) you should be able to adapt this as necessary (e.g. to leave some free space for an allocator tag or something). You can of course wrap this in a function that comes with your allocator if you want. But I don't think it really requires any further API support from the CBFS core? (If we need this sort of "DMA allocator" on many boards, we could of course put it in lib/, including a function that wraps cbfs_load().)
To view, visit change 39304. To unsubscribe, or for help writing mail filters, visit settings.
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Gerrit-Change-Number: 39304
Gerrit-PatchSet: 18
Gerrit-Owner: Julius Werner <jwerner@chromium.org>
Gerrit-Reviewer: Aaron Durbin <adurbin@chromium.org>
Gerrit-Reviewer: Alexander Couzens <lynxis@fe80.eu>
Gerrit-Reviewer: Andrey Petrov <andrey.petrov@gmail.com>
Gerrit-Reviewer: Angel Pons <th3fanbus@gmail.com>
Gerrit-Reviewer: David Guckian <david.guckian@intel.com>
Gerrit-Reviewer: Evgeny Zinoviev <me@ch1p.io>
Gerrit-Reviewer: Felix Held <felix-coreboot@felixheld.de>
Gerrit-Reviewer: Frans Hendriks <fhendriks@eltan.com>
Gerrit-Reviewer: Huang Jin <huang.jin@intel.com>
Gerrit-Reviewer: Hung-Te Lin <hungte@chromium.org>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk@gmail.com>
Gerrit-Reviewer: Lee Leahy <leroy.p.leahy@intel.com>
Gerrit-Reviewer: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd@gmail.com>
Gerrit-Reviewer: Michal Motyl <michalx.motyl@intel.com>
Gerrit-Reviewer: Patrick Georgi <pgeorgi@google.com>
Gerrit-Reviewer: Patrick Rudolph <siro@das-labor.org>
Gerrit-Reviewer: Philipp Hug <philipp@hug.cx>
Gerrit-Reviewer: Suresh Bellampalli <suresh.bellampalli@intel.com>
Gerrit-Reviewer: Vanessa Eusebio <vanessa.f.eusebio@intel.com>
Gerrit-Reviewer: Wim Vervoorn <wvervoorn@eltan.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit-Reviewer: ron minnich <rminnich@gmail.com>
Gerrit-CC: Paul Menzel <paulepanter@users.sourceforge.net>
Gerrit-Comment-Date: Tue, 08 Dec 2020 01:50:52 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Hung-Te Lin <hungte@chromium.org>
Comment-In-Reply-To: Julius Werner <jwerner@chromium.org>
Gerrit-MessageType: comment