In article <43F4A2E9.9030705@tadpole.com>,
Garrett D'Amore <garrett_damore@tadpole.com> wrote:
>I've noticed an annoyance in bus_space while trying to implement new
>bus_space support for Alchemy busses.
>
>bus_space_subregion() creates a new bus_handle_t (derived from a parent
>mapped bus space), but there is no way to clean it up properly.  You
>cannot call bus_space_unmap(), etc. on these.
>
>For most (all?) current NetBSD bus implementations it is a non-issue
>because the bus_space_handle_t is typically just a virtual address.  But
>the framework currently could just as easily support having a
>bus_space_handle_t be a pointer to a structure with e.g. book-keeping
>information, etc. in it.  I actually started a bus_space implementation
>down this road before I discovered this problem.  (I've found an
>alternate approach for my particular case, so its not a stopper for me.)
>
>Anyway, if someone wants to allocate e.g. a structure from the heap to
>create a bus_space_handle_t, then there has to be a way to clean it up
>to avoid leaking the memory.
>
>I am therefore proposing a new API be added:
>
>void bus_space_subregion_free(bus_space_tag_t, bus_space_handle_t);
>
>This frees a bus_space_handle_t allocated by bus_space_subregion().
>
>For all existing bus implementations this routine could be #define'd to
>a nop:
>
>#define bus_space_subregion_free(t,h) { }
>
>The bigger issue, as I see it, is changing the callers of
>bus_space_subregion() so that they free the handle when they need to.
>
>Thoughts?

If we are going to institute bus_space_subregion_free(), I think that
bus_space_subregion() should be renamed to bus_space_subregion_alloc().

christos