On 2025-04-28 02:41, Jan Beulich wrote:
On 26.04.2025 03:53, Daniel P. Smith wrote:
On 4/23/25 15:27, Jason Andryuk wrote:
On 2025-04-19 18:08, Daniel P. Smith wrote:
The bzimage logic uses the unit global orig_image_len to hold the
original
module length for the kernel when the headroom is
On 26.04.2025 03:53, Daniel P. Smith wrote:
> On 4/23/25 15:27, Jason Andryuk wrote:
>> On 2025-04-19 18:08, Daniel P. Smith wrote:
>>> The bzimage logic uses the unit global orig_image_len to hold the
>>> original
>>> module length for the kernel when the headroom is calculated. It then
>>> uses
On 4/23/25 15:27, Jason Andryuk wrote:
On 2025-04-19 18:08, Daniel P. Smith wrote:
The bzimage logic uses the unit global orig_image_len to hold the
original
module length for the kernel when the headroom is calculated. It then
uses
orig_image_len to locate the start of the bzimage when the exp
On 4/23/25 15:27, Jason Andryuk wrote:
On 2025-04-19 18:08, Daniel P. Smith wrote:
The bzimage logic uses the unit global orig_image_len to hold the
original
module length for the kernel when the headroom is calculated. It then
uses
orig_image_len to locate the start of the bzimage when the exp
On 2025-04-19 18:08, Daniel P. Smith wrote:
The bzimage logic uses the unit global orig_image_len to hold the original
module length for the kernel when the headroom is calculated. It then uses
orig_image_len to locate the start of the bzimage when the expansion is done.
This is an issue when mor
The bzimage logic uses the unit global orig_image_len to hold the original
module length for the kernel when the headroom is calculated. It then uses
orig_image_len to locate the start of the bzimage when the expansion is done.
This is an issue when more than one bzimage is processed by the headroo
