MTD concat layer

[Robert Kaiser]

Hi,

attached is my first version of the MTD "concatenation layer".
This basically allows to build virtual MTD devices by concatenating
existing ones, so it is -in a way- the opposite of partitioning.
I would like to add this to the MTD CVS and so I'm asking people
to have a look at it.

I see two possible uses for this:

1) Having flash filesystem volumes span multiple physical chips
   I have recently seen several people ask for this on the mailing list.

2) Allow re-ordering of blocks in flash chips.
   This is my personal reason for writing this code.  It requires
   some explanation:

   I have this cute DIL/NetPC module that -for technical reasons-
   has it's BIOS right in the middle of the 2MB flash. The mapping
   driver creates partitions reflecting this hardware-imposed map.
   However, this map is very unfortunate in many cases. Specifically,
   it would be nice if one could move the BIOS block out of the way
   and treat the flash portions below and above that BIOS block as
   one contiguous device that can then be partitioned arbitrarily.
   The concat layer allows just that: I can concatenate the physical
   partitions into a single device, specifying the sequence such
   that the BIOS block appears at the end and then re-partition
   that new (virtual) device as to my heart's desire :-)


Q: Why not do this in the mtdpart layer ?

David suggested at some point that this should be done in the
partitioning layer:

dwmw2 said:
> It doesn't need to be an extra layer. Splitting a single device into 
> multiple 'partitions' and building a big 'partition' from multiple devices 
> are just two cases of the same thing - munging the offsets and passing the 
> request off to a 'master' device. 

I tried to hack up the mtdpart.c accordingly, but came to the conclusion
that it is impossible to implement this without causing significant
overhead for parties that use only partitioning or only concatenating,
so it seemed cleaner to do it in a seperate layer. Moreover, the current
partitionining layer is scheduled to be replaced in the near future by
Jörn Engel's code, so I thought it best to stay clear of that layer of
code.

There are two patches attached to this mail:

1) patch-mtd-concat

This contains the actual concat layer. It also modifies the sc520cdp.c
mapping driver to demonstrate how use it by concatenating
the sc520cdp's two flash banks into one MTD device.

The concat code is in drivers/mtd/mtdconcat.c
This code defines two extenal functions:

-mtd_concat_create() to build a virtual MTD device by concatenating
 existing MTD devices.

-mtd_concat_destroy() to destroy an MTD object obtained from
 mtd_concat_create()

There is a header file (incluce/linux/mtd/concat.h) defining the
prototypes of these functions.

2) patch-mtd-concat-part

This patch modifies the DIL/NetPC mapping driver to re-order flash
blocks as described above. It also modifies the partitioning layer
(which is why I've made this a seperate patch): The current partitioning
layer has the habit of always registering the partitions as MTD devices
and not giving the caller access to the device objects it creates. I've
changed this (in a backward compatible way) because I do not want the
intermediate layers (i.e. the physical partitioning) to appear
as MTD devices. (I believe JÖrn's new partitioning code deals with this
too, though probably in a different way.)

Shortcomings I'm aware of so far (suggestions welcome):

* Currently, all sub-devices are expected to be of the same type.
  It might be reasonable to allow concatenating certain combinations
  of different types, where the super device would be assigned a
  "least common denominator" type (i.e. if combining ROMs with flashes,
  would yield a ROM, etc.).

* I'm not sure how to assign flags to the concatenated device. Right now,
  all but the writeablility flag have to be the same.

* Currently, all sub-devices are expected to have the same OOB and
  ECC info. I must admit that I don't have enough clue about these
  things to tell wether it might make sense to concatenate devices
  with differring OOB and/or ECC info. So by default, I'm not allowing it.

* The readv()/writev() functions are not implemented. The reason is that
  so far I could not conceive of a way to do this that would not result
  in terribly messy code. Also, it is my impression that these functions
  are not very important anyway (I might be wrong, here..).


Thanks for any suggestions

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser at sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-mtd-concat.gz
Type: application/x-gunzip
Size: 4752 bytes
Desc: 
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020212/13d35313/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-mtd-concat-part.gz
Type: application/x-gunzip
Size: 3034 bytes
Desc: 
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020212/13d35313/attachment-0001.bin