MTD concat layer

[Robert Kaiser]

Hi,

here is my second attempt of an MTD concat layer. The issues that
David found with the first one have (hopefully) been fixed. I have also
made some benchmarks comparing MTD performance on the platforms I have
at my disposal (DIL/NetPC and SC520CDP) with vs. without concat layer.

Judging by these benchmarks it seems to me that the performance impact of
the concat layer is almost negligible.

On 21 Feb 2002, Jonas Holmberg wrote:

> On Wed, 2002-02-20 at 16:35, Robert Kaiser wrote:
> > The erase function has a bug for which I'm currently developing
> > a fix. I hope to get it done by tomorrow.
> I'm awaiting your erase-fix.

As usual, it took a little longer than expected, but finally here it is :)

> It seems like JFFS uses writev. Are you planning to implement the
> v-functions?

Yes, Both jffs and jffs2 use it, but both also have a substitute routine
in case the driver doesn't provide one. Of course I could hack up
what would basically be a copy of mtd_fake_writev() from jffs2/wbuf.c
and add that to mtdconcat.c, but I think that would be wrong (see
the comment in jffs2/wbuf.c, BTW).

> 
> > 
> > > When can we expect to see this in CVS?
> > 
> > Good question :-). Apparently David is not yet completely convinced
> > that it should be implemented the way I did. If you do some serious
> > testing, your test results might help to persuade him (or prove to him
> > that his scepticism was right). In any case, please share your
> > results.
> 
> Is it much work implementing it his way instead?

The simple cases like read/write, etc. will probably not be hard
to do in the partition layer. However, if you look at the new concat_erase
function, I do not think it has much in common with the one in
in mtdpart.c. Also the actual merging of MTD devices (i.e. generating
a singe device object that reflects the properties of multiple underlying
device objects) seems fundamentally different to me from what the
partitioning layer does, but maybe I'm already so focused in my idea
that I can't see the alternatives...

> Your concat layer looks very clean, but David use to be
> right :-)

I believe David's biggest objection was the potential loss of performance
due to the stacking of layers. I hope the benchmarks I made show that this
is not a problem.

Cheers

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: 5759 bytes
Desc: New concat layer
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020226/00314bce/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-mtd-concat-part.gz
Type: application/x-gunzip
Size: 2949 bytes
Desc: Additional concat stuf w/ slight modification to partitioni
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020226/00314bce/attachment-0001.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Benchmark.txt
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20020226/00314bce/attachment.txt