All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.