[MTD partitioning rewrite]

[Eric]

> [ ... ] might even grow into a complete rewrite of the central 
> MTD code. We will see, how much is needed...

I applaud your decision to modify the partitioning scheme, and in
a few areas the central code could use spring-cleaning; however, 
a re-write of the central code is scary business unless you have
a lot of hardware with which to test and folks here aggressively 
audit the work.  I have yet to see "re-writes" that did not impact
the codebase stability.

> - An MTD device will be the equivalent of a hard drive. There will be
> several, named mtda, mtdb, mtdc,...

Hooray!  This would be a welcome change.  Perhaps we can also eliminate
the restriction of 16 char device maximum (yes, it does affect me in a
non-academic way).

> - The ro-devices don't seem to be necessary. If noone has strong
> objections, I will just discard those.

No complaints here.

> - The partitioning should stay out of the mapping drivers as much as
> possible. The mapping driver only supplies a pointer to the partition
> table parser. When the device is registered, the partitioning will
> automatically be read.

I'd like more implementation details, but the separation is welcome.
It does seem a bit silly to re-write the mapping driver just for a
new partitioning scheme.  Perhaps we can treat it like a disk in 
this regard and "scan" it for a partition table.

> If anyone has questions, comments, code sniplets, ideas, anything, you
> can contact me privately on through the list. I will only try to do
> the best, _I_ can do and hope, David approves it.

Sounds like a worthy plan to me.  I'd suggest holding-off on the 
"complete rewrite" until after this new functionality has been
added, though :)

E