public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] extend physmap.c to support run-time configure and partitioning (take 3)
Date: Mon, 10 Nov 2003 15:19:18 -0800	[thread overview]
Message-ID: <20031110151918.D19785@mvista.com> (raw)
In-Reply-To: <20031106110921.G19785@mvista.com>; from jsun@mvista.com on Thu, Nov 06, 2003 at 11:09:21AM -0800

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

)

David,

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(....)
	...
	physmap_unset_map(mtd)

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
  now,
. during kernel exit time, we clean it up.

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

Jun

      reply	other threads:[~2003-11-10 23:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-05  0:44 [PATCH] extend physmap.c to support run-time configure and partitioning (take 3) Jun Sun
2003-11-05  9:14 ` David Woodhouse
2003-11-05 17:56   ` Jun Sun
2003-11-06  9:50     ` David Woodhouse
2003-11-06 19:09       ` Jun Sun
2003-11-10 23:19         ` Jun Sun [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031110151918.D19785@mvista.com \
    --to=jsun@mvista.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox