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

[Lars Heidieker <lars%heidieker.de@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
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 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2gNmkACgkQcxuYqjT7GRbJXwCeIjf377XJxctHpMNBt5+WjcPr
1YYAn1JVbfJFju+OEfu/Fs0DX1kj2gnI
=5AAO
-----END PGP SIGNATURE-----