Searched hist:a4578d1a2a1887f67dd4fbf1c3d4325449c6618b (Results 1 – 3 of 3) sorted by relevance
| /rk3399_rockchip-uboot/include/ |
| H A D | abuf.h | a4578d1a2a1887f67dd4fbf1c3d4325449c6618b Sat Sep 25 13:03:07 UTC 2021 Simon Glass <sjg@chromium.org> UPSTREAM: Add support for an owned buffer
When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.
Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.
Introduce a new 'abuf' which supports simple buffer operations:
- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed
This simple API makes it easier to deal with allocated and memory-mapped
buffers.
Signed-off-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 67bc59df05331eaac56cd0a00219d1386130aee2)
Change-Id: I1445cda254d266705d5f76ba1f9d1046408807bf
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
|
| /rk3399_rockchip-uboot/lib/ |
| H A D | abuf.c | a4578d1a2a1887f67dd4fbf1c3d4325449c6618b Sat Sep 25 13:03:07 UTC 2021 Simon Glass <sjg@chromium.org> UPSTREAM: Add support for an owned buffer
When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.
Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.
Introduce a new 'abuf' which supports simple buffer operations:
- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed
This simple API makes it easier to deal with allocated and memory-mapped
buffers.
Signed-off-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 67bc59df05331eaac56cd0a00219d1386130aee2)
Change-Id: I1445cda254d266705d5f76ba1f9d1046408807bf
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
|
| H A D | Makefile | a4578d1a2a1887f67dd4fbf1c3d4325449c6618b Sat Sep 25 13:03:07 UTC 2021 Simon Glass <sjg@chromium.org> UPSTREAM: Add support for an owned buffer
When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.
Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.
Introduce a new 'abuf' which supports simple buffer operations:
- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed
This simple API makes it easier to deal with allocated and memory-mapped
buffers.
Signed-off-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 67bc59df05331eaac56cd0a00219d1386130aee2)
Change-Id: I1445cda254d266705d5f76ba1f9d1046408807bf
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
|