Re: krealloc()

Re: krealloc()

[Manfred Spraul]

John Moser wrote:

>I'm not sure if I should just call mmap() inside the
>kernel (any security hazzards or whatnot I should be worried about there?), but
>it's going to be a pain to resize arrays.
>
mmap only works for user space memory, not for kernel memory.

>Most realloc() implimentations grow or shrink in place, if possible.  If they can't,
>or if that wasn't how they were coded, they allocate the new block, memcpy() over,
>then free the old block.
>
>  
>
The kmalloc implementation is object based, it cannot grow in place. The 
only approach is call ksize and check if it fits by chance, otherwise 
alloc new block and memcpy, then free.
Why do you need realloc? What do you want to do? Are you aware that 
kmalloc is limited to 128 kB, and that large kmallocs (I'd guess: > 16 
kB) can fail due to memory fragmentation after long uptimes?

--
    Manfred

krealloc()

[john moser]

Why is there no krealloc()?  I'm not sure if I should just call mmap() inside the
kernel (any security hazzards or whatnot I should be worried about there?), but
it's going to be a pain to resize arrays.  realloc() is usually:

void *realloc(void *block, size_t size);

I'm thinking krealloc would be the same, since we'd have the old GFP_* flags and
the old size:

void *krealloc(void *block, size_t size);

Most realloc() implimentations grow or shrink in place, if possible.  If they can't,
or if that wasn't how they were coded, they allocate the new block, memcpy() over,
then free the old block.

I have nowhere near the skill or experience needed to impliment any sort of
krealloc(), so for now I'm going to have to do bad hacks in my code.  Can someone
please impliment a krealloc() by 2.6.2?  Or at least slate it for SOME time in the
future, if not immediately now.

_____________________________________________________________
Linux.Net -->Open Source to everyone
Powered by Linare Corporation
http://www.linare.com/