Re: [GIT PULL] x86: add brk allocator for very early allocations

[Jeremy Fitzhardinge]

Eric W. Biederman wrote:
> extend_brk is the wrong way to go.  We already have a better mechanism.
> find_e820_early paired with reserve_early.
>   

No doubt that's a better option when available.  But I want to allocate 
earlier than that.

> Allocating the early page tables are a very special case.   There is
> a case for cleaning up that mechanism and making more comprehensible.
> We should not be generalizing it, and making the kernel more fragile.
>   

More fragile?  I don't see that extend_brk() is a particularly fragile 
mechanism.  I guess a user could start over-using it and running out of 
the initial space.  That would fail in a fairly unambiguous way (there's 
a BUG_ON checking for an attempt to extend beyond __brk_limit), and 
would definitely be an abuse of the call.

My motivation for this patch is to dynamically allocate things very 
early, before the e820 map is available.  Specifically, I want to 
dynamically allocate various Xen datastructures which would otherwise 
statically waste space in the bss (in the case where you're running a 
Xen-enabled kernel on a non-Xen system).  It also allows me to scale 
them according to the memory size, etc.  I need to do this before e820 
is available; indeed, I need to do it to synthesize an appropriate e820 
map for the kernel to consume.

It is also nice that it generalizes head_32.S's pagetable construction, 
and mops up the bespoke DMI allocator.  There may well be some other 
potential users.  I think any static data in bss is fair game, 
particularly if it is only used conditionally.

   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/