[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.076 / U:3.792 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site