[PATCH 13/22] remove erase regions

[Jörn Engel]

On Tue, 21 December 2004 19:47:00 -0700, Eric W. Biederman wrote:
> "Christopher Hoover" <ch at murgatroid.com> writes:
> > >From Jörn Engel [mailto:joern at wohnheim.fh-wedel.de] - 
> > > On Tue, 21 December 2004 10:42:07 -0800, Christopher Hoover wrote:
> > > > >From Jörn Engel -
> > > > > I see absolutely no reason for complicated erase reagions.  On the
> > > > > user side, everyone but mtdchar effectively ignores it anyway.
> > > > 
> > > > I don't grok this.   What about flash with variable-sized 
> > > blocks?  (I have a
> > > > board with such flash and code that uses eraseregions.)
> > > 
> > > Sure, from AMD or some other compatible manufacturer.  The
> > > variable-sized blocks were nice until there were better solutions to
> > > the problem, like jffs2.  Jffs2 exists, so they are largely useless.
> 
> jffs2 is only a solution on large NOR flash parts.

True.  I've been meaning to scale jffs2 down, but never found the
time.

> However I find this conversation confusing.  The patches appear to affect
> just mtdblock.c.

The other way around, blockmtd.c.  Which is a cleaned up version of
blkmtd.c.  It turns a block device into an mtd device, not vice versa.
Name is confusing, so if you have a better one...

> Which sounds like it is exclusively the mtd block device.
> At which point I don't see a problem with simply removing variable erase
> size for the silly block device emulation code.
> 
> Now if someone wants to remove something silly the block device emulation
> sounds like a fine place to start.  Just to place the silliness on the
> other foot.

Both emulations have valid uses:
mtd -> block device:
Very simple block devices.  It is much simpler to write an mtd device
than a block device.  Right now, all known-to-me users of phram use it
as a block device.

block device -> mtd:
Cheap flash media.  Jffs2 helps on usb sticks as well, so turn those
puppies into mtds and be done.

> > > 5 does, but is horribly ugly and noone cares enough to clean it up. 
> 
> If it ain't broke don't fix it.  Besides I have trouble seeing how 500 lines
> of code can be horribly ugly.  

o read-only devices that confuse every single new user
o #define MAX_KMALLOC_SIZE 0x20000
o FIXME: This _really_ needs to die. In 2.5, we should ...

> > This is not a reason to toss it.  We don't capriciously break user space
> > interfaces in Linux.

I don't.  Instead I take a driver I'm unhappy with, copy it, and
change the parts I don't like in the copy.  Nothing breaks on your
side.

> > Also this:
> > 
> > 6. The hook that unlocks locked-on-power-up flash, such as (*surprise*) C3
> > flash.  It needs to call unlock with the start address of each block.  It
> > needs eraseergions to do that.
> 
> If Christopher is reading this right I agree that killing variable
> erase sizes across the board is a very bad idea.

He isn't.

To finally lift all the confusion:
This is about the blockmtd driver, nothing else.  Said driver takes a
block device and turns it into an mtd.  And for an bd-based mtd, there
is _no_ point in having complicated erase regions.

For regular flash, I consider them to be silly as well, but there are
so many silly things that people like.  Let them have fun, as long as
noone gets hurt.

Jörn

-- 
The only real mistake is the one from which we learn nothing.
-- John Powell