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
prev parent 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