Subject: bus_space annoyance, API change proposal
To: None <tech-kern@NetBSD.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 02/16/2006 08:06:01
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?

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191