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

Jun Sun
2003-10-29T23:14:31Z

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