[MTD partitioning rewrite]
ebrower at usa.net
Wed Oct 17 13:53:21 EDT 2001
> [ ... ] 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
> - 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 :)
More information about the linux-mtd