-----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-----
