Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/39304 )
Change subject: cbfs: Simplify load/map API names, remove type arguments ......................................................................
Patch Set 18:
(1 comment)
https://review.coreboot.org/c/coreboot/+/39304/3/src/lib/cbfs.c File src/lib/cbfs.c:
https://review.coreboot.org/c/coreboot/+/39304/3/src/lib/cbfs.c@209 PS3, 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().)