[PATCH] extend physmap.c to support run-time configure and partitioning (take 3)

Jun Sun jsun at mvista.com
Mon Nov 10 18:19:18 EST 2003

On Thu, Nov 06, 2003 at 11:09:21AM -0800, Jun Sun wrote:
> On Thu, Nov 06, 2003 at 09:50:07AM +0000, David Woodhouse wrote:
> > On Wed, 2003-11-05 at 09:56 -0800, Jun Sun wrote:
> > > Hmm, can you be more specific?  Here are all static variables that
> > > matter in physmap.c.  Which ones are you thinking to eliminate?  And in 
> > > what way?  (Assuming you do not mean I just drop "static" modifier...)
> > 
> > I mean mymtd, in particular. 
> > 
> Can you explain how to eliminate that?
> All mapping drivers keep a static pointer to remember the mtd info
> it discovers so that it can free it later.  Are you suggesting
> we get rid of the exit function and we don't free it?

(This replies to the IRC discussion David and I had:

<jun> around?  I am really confued by your comment of eliminating "mymtd" variable.  Can you elaborate?
<jun> either we get rid of the exit cleanup function, or somehow we can retrieve this pointer without resorting to the static variable..
<jun> either way the solution is not obvious to me.
<dwmw2> get rid of the exit cleanup function, let the caller do that



If I understand you correctly, you essentially want to make
physmap_set_map() do what init_physmap() does, and have 
physmap_unset_map() do what cleanup_physmap() does, right?  That 
would also explain your desire of having

	mtd = physmap_set_map(....)

Well, unfortunately that does _not_ work because run-time configuration
should run in the board setup code which is too early for what 
init_physmap() is doing (for example, such as ioremap() because trap_init()
has not run yet).

In order for the whole thing to work, the most obivous solution is 
to have three steps :

. during board setup time, call run-time configure routine, which remember
  arguments in local static variables
. during do_initcalls() time, we do physmap_init() like it is doing right
. during kernel exit time, we clean it up.

Does that make sense?  Do you have any more objections to the current patch
(take 3)?


More information about the linux-mtd mailing list