All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.