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

[Jun Sun <jsun@mvista.com>]

On Wed, Oct 29, 2003 at 04:57:27PM -0600, Cam Mayor wrote:
> On Wednesday 29 October 2003 12:45, Jun Sun wrote:
> > On Wed, Oct 29, 2003 at 11:13:26AM +0000, David Woodhouse wrote:
> > >
> > > That's nicer. Why multiple physmap_add_partition() calls rather than
> > > just a single array passed to physmap_set_map() though?
> >
> > Hmm, currently partition only matters when CONFIG_MTD_PARTITIONS
> > is enabled.  I assume this mean sometimes people want to use
> > physmap without partitions.  True?
> 
> Yes.  We have a product that partitions physmap (from the kernel command 
> line), but also uses the unpartitioned physmap base device. 
> 
> ie. physmap on /dev/mtd0
>     physmap partitions on /dev/mtd1, /dev/mtd2, etc.   sometimes none.
> 

Thanks for the data point.  

My original comment is really a question to David: do we really
want "partition" to be an argument in phsmap_set_map() even when
CONFIG_MTD_PARTITIONS is _not_ configured?

If David does not like multiple add partition calls, we can
easily introduce another interface function:

 	physmap_set_partitions(partitions)

So it seems like we have three possibilities in terms
how a board tells physmap driver about the partitions:

1) lumped in physmap_set_map() (as David suggested)

2) calling adding parition multiple times (as in my original
   proposal)

3) calling adding partitions in one shot with an array.

I don't like 1) because of CONFIG_MTD_PARTITION issue.  But if
David insists, I can modify patch as such.

Jun