From: Jun Sun <jsun@mvista.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] extend physmap.c to support run-time adding partitions
Date: Thu, 23 Oct 2003 10:03:04 -0700 [thread overview]
Message-ID: <20031023100304.B1070@mvista.com> (raw)
In-Reply-To: <20031023153307.GA11669@wohnheim.fh-wedel.de>; from joern@wohnheim.fh-wedel.de on Thu, Oct 23, 2003 at 05:33:07PM +0200
On Thu, Oct 23, 2003 at 05:33:07PM +0200, Jörn Engel wrote:
> On Wed, 22 October 2003 18:25:58 -0700, Jun Sun wrote:
> >
> > While looking at drvers/mtd/maps directories, it becomes
> > obvious to me that many files are derived from physmap.c,
> > in order to add partition support or add their own
> > set_vpp() pointer, etc..
> >
> > Such a need can be easily satisfied by extending physmap.c
> > a little.
> >
> > In this patch, I like to introduce phsmap_add_partition()
> > function, which allows boards to add flash partitions
> > at run-time. (Note that you can still override this
> > hardcoded partition by using kernel command line)
> >
> > In the patch I also showed how a board can make use of this
> > extension. Hopefully we can get rid of lots of files under
> > the maps directory. :)
>
> For most people, you saved source code size and wasted binary size.
> The very same people are far more concerned about binary size. :)
>
Ahh, note that I turned a couple of functions and data into
__init kind. That should make space-conservative people happy.
> I've tried to clean this up before and failed, but maybe you can do a
> better job. Good luck!
>
What was the main objection? I can list quite a few benefits:
1. remove _lots_ of duplicated mapping files, which also means
a cleaner CONFIG_xxx space and a simpler Makefile.
2. the board-specific partition setup is now done in arch/<xxx>/<board>/setup.c
which means when a board is deleted, its flash support is automatically
removed. (Not so with current arrangement)
3. futher _common_ improvement is possible. For example, for most MIPS boards
we don't need ioremap to access the flash area - CPU has a fixed uncached
mapping to physical space. Now we can just modify one file and benefts
about almost 20 boards.
Jun
next prev parent reply other threads:[~2003-10-23 17:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-23 1:25 [PATCH] extend physmap.c to support run-time adding partitions Jun Sun
[not found] ` <20031023153307.GA11669@wohnheim.fh-wedel.de>
2003-10-23 17:03 ` Jun Sun [this message]
2003-10-23 17:31 ` Jörn Engel
2003-10-23 17:43 ` Jun Sun
2003-10-23 18:15 ` Jörn Engel
2003-10-23 20:04 ` Jun Sun
2003-10-23 23:57 ` Jun Sun
2003-10-28 8:22 ` Holger Schurig
2003-10-29 2:33 ` Jun Sun
2003-10-27 18:17 ` Jun Sun
2003-10-28 10:50 ` David Woodhouse
2003-10-29 2:28 ` Jun Sun
2003-10-29 11:13 ` David Woodhouse
2003-10-29 18:45 ` Jun Sun
2003-10-29 19:32 ` Jörn Engel
2003-10-29 23:15 ` Jun Sun
2003-10-29 22:57 ` Cam Mayor
2003-10-29 23:13 ` Jun Sun
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=20031023100304.B1070@mvista.com \
--to=jsun@mvista.com \
--cc=joern@wohnheim.fh-wedel.de \
--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.