On Thu, Jan 09, 2003 at 11:13:08PM +0100, Jaromir Dolecek wrote:
> Normally you use malloc(9) or pool(9) routines. Of course, disadvantage
> of malloc(9) is that it allocates memory from interrupt-safe kernel
> memory pool, which has certain fixed upper size.
> 
> You don't need to play directly with vm_space structures when
> you use uvm_km_zalloc(). The returned vaddr_t can be directly
> used for your data within kernel. If the memory is accessed
> from process context always, you might consider using
> uvm_km_valloc{_wait}(), which IIRC doesn't wire the memory
> and demand-fills the virtual address range with physical pages.


You said i don't need to manipulate vm_map* structures. You're right (
although i had a lot of fun writing the algorithm :).

But let me ask another question. Does uvm_km_alloc alloc contiguous
pages ? (it's not said in the man page, and i am unsure of the meaning
of wired)

If this is the case, i am gonna rewrite that ...

> Hopefuly this helps a little,

Sure it does :-)

Thanks,

David

> David Ferlier wrote:
> > Hi,
> > 
> > I am writing a piece of code (a filesystem), and i need to alloc kernel memory of
> > a dynamic size for bitmap cache stuff.
> > 
> > For the moment, i alloc'ed all that with uvm_km_zalloc, and then i read the
> > vm_space structure, and do a loop over all the vm_map_entry structures it contains.
> > 
> > I didn't test the code, but i'd like to know which of the uvm api or malloc(9) api (with
> > a special type specific to the filesystem) to choose (before going further)
> > 
> > Thanks in advance.
> > 
> > -- 
> > 
> > David Ferlier	- david@netbsd-fr.org     || 
> > 		  dferlier@BonBon.net
> > 
> > www.NetBSD.org	- Of Course It Runs NetBSD
> > 
> 
> 
> -- 
> Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
> -=- We should be mindful of the potential goal, but as the tantric    -=-
> -=- Buddhist masters say, ``You may notice during meditation that you -=-
> -=- sometimes levitate or glow.   Do not let this distract you.''     -=-
> 

-- 

David Ferlier	- david@netbsd-fr.org     || 
		  dferlier@BonBon.net

www.NetBSD.org	- Of Course It Runs NetBSD