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 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.