vmem problems [was: Re: extent-patch and overview of what is supposed to follow]

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Lars Heidieker <lars%heidieker.de@localhost> wrote:
> >> this is a part of the changes to the kernel memory management.
> >> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> >> essentially removing the MALLOC_TYPE from it.
> > Why start from this end, instead of converting extent(9) uses to vmem(9)
> > and then just retire extent(9) subsystem?
> >
> There are problems with vmem in the general case as David Young pointed
> out http://mail-index.netbsd.org/tech-kern/2009/12/03/msg006566.html
> 
> Therefore my idea is to have a resource allocator that combines the
> properties of both nothing I have started with except of thinking about
> it. eg vmem is returning null in the error case which results in problem
> when the resource range should include 0 and making offset wrappers...

Just to come back on this..

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?

Therefore, I would say requirements of potential vmem(9) users should be
investigated and understood first.  Our vmem(9) API is now compatible with
Solaris.  If these are indeed real problems, we can decide to diverge.

-- 
Mindaugas