tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: vmem problems [was: Re: extent-patch and overview of what is supposed to follow]

Hash: SHA1

On 04/09/11 12:25, Lars Heidieker wrote:
>> Third problem i.e. vmem(9) relying on malloc(9) is something
>> what
> needs
>> fixing, yes. VMEM_ADDR_NULL being 0 does not look like a major
> problem,
>> a simple offsetting would work around it, but perhaps
>> (vmem_addr_t
> *)-1
>> would help as well (if its users do not need the whole range, but
>> need a start at 0). And this gets related to problem 2 about
> ~(vmem_addr_t)0
>> being the maximum value in the range - is there a need for a
>> wider
> space?
> The changed kmem implementation I made does not rely on vmem and
> therefore vmem can use kmem then instead of malloc. This solves
> the third problem.
It fixes the problem in the sense, that it does not require malloc as
a seperate allocator, it does not fix the early boot allocation, where
the kernel maps are not available.... currently I can't think about
another way around this, than to give vmem memory on arena creation
like extent or to have a global pool a static boundary tags, that is
large enough for bootstrap..

- -- 
- ------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Home | Main Index | Thread Index | Old Index