Re: [PATCH] extend physmap.c to support run-time adding partitions

[Jun Sun <jsun@mvista.com>]

On Thu, Oct 23, 2003 at 07:31:48PM +0200, Jörn Engel wrote:
> On Thu, 23 October 2003 10:03:04 -0700, Jun Sun wrote:
> > 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.
> 
> __init still shows up in flash, though.
> 
> > > 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.
> 
> o All those translate to improvements in the source code.  How about the
> binary?  Compile with and without patch and post the kernel image
> size.  And remember that noone will use two map files at the same time
> in the real world.
> 
> o Copy and paste is simple.  So simple in fact, that everyone does it,
> as you have observed.  Why make it more complicated, unless you have
> clear advantages.
> 

... as if my previous listings are not advantages. :)

> 
> Yes, I like the basic idea, tried to do it myself.  But what's the use
> if all your users care about binary size and that increases?
>

I find it hard to belive this patch would increase kernel size.
Can someone using existing propriatary mapping driver apply this 
patch, switch to use physmap.c, and let us know the size increase?

How much increase would you start to really care in a typical .5M to 2M
kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.

Actually I don't see any increase at all if the proprietary file is a strict copy
of physmap.c.

Jun