Subject: Re: realloc part 2
To: Bill Studenmund <wrstuden@loki.stanford.edu>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
List: tech-kern
Date: 08/26/1996 14:12:01
> A while back, I asked about porting code which uses realloc, and I got
> good advice. I have some more questions, though.
> 
> This is all code in the kernel. Someone else and I are porting a
> mac fs filesystem package to NetBSD.
> 
> 1) Given the old pointer, is there some routine I can call to find out
> how much space the old allocation had? I need to copy the old data over,
> but I don't know how much to move.

Uh, realloc() should copy the data itself.  I created (but did not
test) an implementation of realloc(), which i believe i sent to this
or another mailing list in response to your earlier queries.

Get in touch with me privately if you need another copy.


> 2) What exactly are the different memory allocation types for? I'm
> adding new type codes, but I'm not sure if I'm using them right.
> Namely some of the fields used in /sys/kern/kern_malloc.c imply
> that the buckets are for allocating things of constant size (I
> guess so that when one is freed, chances are it gets reused for
> something the same size, reducing fragmentation).

the types are not used for anything other than statistics collection.
The _sizes_ determine what buckets things go into...


> But at times, I want to malloc disk buffers. Shoudl I just make up a
> new memory type and not worry, or is there a better memory type to use?

What do you mean "malloc disk buffers"?

If you actually want real buffers, you should be using ... buffers
obtained via the buffer cache, not malloc()ed.

If you want to just allocate some space to store a cached copy of
something in a disk buffer, then that's another thing entirely...
and you should just use malloc with an appropriate type.  File systems
are welcome to (and commonly do) define their own allocation types.



chris