Re: MTD concat layer

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

Hi!

> >  Hmm, I agreed with you about this before I actually attempted coding
> > it this way, but the code turned out to be a mess. IMHO, it is _much_
> > cleaner as a seperate layer. What would be the advantage of merging it
> > into the partition code ?
> 
> Fewer wrapper layers to go through. Look at the part_read() call I 
> implemented - is that really so bad for the case where people don't have 
> multiple 'sections' in each partition?

Are fewer wrapper layers really an advantage? They don't improve
maintainability or correctness, nor do they give new features.
An additional wrapper only needs one additional function call, so
execution time should not degrade much. But it will actually improve,
whenever you don't need the additional layer.

> > - significant effort, specifically since the current partitioning
> >   code is scheduled for replacement by Jörn's code, so I'd have to
> >   do it twice. 
> 
> Jörn's code needs to provide this functionality to be merged - making sure 
> there's no regression is part of the work necessary for merging the new 
> stuff, and wouldn't necessarily fall to you.

Ack.
Apart from that, it is often quite a good idea to write the same code
twice. First implementations usually suck, especially mine.

Jörn

-- 
You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike