cvs commit: src/sys/kern kern_subr.c src/sys/sys systm.h src/share/man/man9 Makefile hashinit.9

[Robert Watson]

On Mon, 15 Jan 2007, Randall Stewart wrote:

>> and why are we useing new flags, btw?  Can't we just pass down the normal 
>> malloc flags?  I seem to remember that we do that in a couple of places 
>> already.
>
> Well... I was game to either method.. I think the general thought was that 
> there may be OTHER non-memory flags that we direct at hash-init someday.. 
> and having them not locked to memory was a good thing..
>
> Robert might care to comment on this one .. of course it can always be 
> changed to be just the memory flags too :-)

Yes -- this is exactly what I have in mind.  Today, the flags simply indicate 
memory allocation disposition, but I think it's reasonable to assume that like 
several other complex object allocators/initializers, we might want additional 
flags in the future.  I think I prefer the sf_buf_alloc() model (custom flags 
mapped as needed into underlying operations), rather than the soalloc() model 
(reuse some but not all memory flags).

Robert N M Watson
Computer Laboratory
University of Cambridge