[lkml]   [2009]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: brk patches..
    H. Peter Anvin wrote:
    > If the brk is bounded-size on the same order or smaller as the kernel,
    > we should just mark it as an unallocated (bss) section in the ELF image
    > and be done with it... there really is no point in trying to be smarter
    > (we'd be subject to failures to load the kernel proper.) If the brk is
    > significantly bigger, then yes, we need to be smarter. However, that is
    > not my current understanding of the requirements.

    Yes, right. And in my case I actually need it to generate an
    appropriate e820 table, so adding a dependency on e820 would be circular...

    (To be specific: I reshape the guest e820 table so that it doesn't have
    memory in any forbidden areas of the host e820 table. That may require
    moving the pseudo-physical address of pages into a new overflow e820
    entry, which would also require allocating pages for the p2m radix tree.)


     \ /
      Last update: 2009-03-02 02:19    [W:0.024 / U:25.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site