[PATCH 06/25] mtd: move ioctl32 code to mtdchar.c

[Josh Boyer]

On Tue, 2005-11-08 at 19:33 +0100, Jörn Engel wrote:
> On Tue, 8 November 2005 11:10:27 -0700, Eric W. Biederman wrote:
> > I can see that argument with respect to mtdblock.  But why would
> > removal of mtdchar be a good thing?  It is a simple raw access
> > interface.   For those whose flash parts are too small for a filesystem
> > or when you are doing things that you can't do with a filesystem
> > like making or checking it you need something like mtd char.  For
> > embedded folks who don't care you can just compile it out.
> 
> mtdchar.c is one of the worst drivers inside the kernel.  The concept
> of having a simple char device driver for flash may have its charm,
> but the actual implementation is horrible.  And things like the
> read-only devices are even unfixable.

Sucky implementation isn't a reason for removal.  It's a reason to fix
sucky implementation.

> 
> mtdblock.c, while being quite a bit more complicated, does not require
> a ton of ioctls, will not confuse users with minor number 7 actually
> being device number 3 and magically being read-only despite unix
> permissions and hardware properties.  Plus, it is just a file.
> 
> Can you name a few examples, where mtdchar.c makes sense?  I've found
> it to be quite useless.

It allows users to write an image to a NAND device that has bad blocks
and not totally screw it up.  This is possible because of those ioctls.
The mtdblock stuff knows nothing of this.

I do agree that the read-only devices don't make sense.  The code itself
probably needs work too.  But until someone takes the time to make the
mtdblock devices have equivalent functionality, mtdchar needs to stay.

(And mtdblock has it's own set of issues as well.  I'd be happy to
discuss them, but I think it would be offtopic for this thread.)

josh