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