[RFC] the way to proceed with OOB data
vwool at ru.mvista.com
Thu Dec 15 05:41:16 EST 2005
you may have noticed the RFC patches for OOB handling rework I've posted
to this list about two weeks ago.
The main idea of those was a) to provide uniform method for handling OOB
by such MTD users like JFFS2/YAFFS2 b) to hide the OOB internal
structure from the users. However, people talking to me on that convined
me that those changes were too radical for the moment and also pointed
out the following problems that arise if my changes are accepted:
1. No more legacy support for jffs/yaffs OOB layouts. This is the point
I don't consider to be major, since if something's deprecated it means
that it'd go away at some point, so maybe now is the time? But maybe
most of you guys think differently.
2. No more ability to read raw OOB data from the userspace which might
turn to be a serious problem while debugging stuff. I must admit this is
something we should preserve.
3. No binary compatibility for MTD utilities. Here I'm also willing to
admit being too radical.
On the other hand, it's really necessary to provide means for kernel
MTD users not to mess with the oobinfos.
So, the question is: how to do it then? I see several ways of doing that.
1. Change the API for nand_read_ecc and nand_write_ecc, namely add OOB
read/write length parameter. This is what Charles proposes; it's nice
for MTD users but it will overcomplicate nand_read_ecc/nand_write_ecc,
which are complicated enough at the moment.
2. Change the API for nand_read_oob/nand_write_oob so that it read/wrote
either raw OOB or free OOB. This way has been discouraged by Artem
during our discussion in #mtd, but this might be an option.
3. Leave everything as is and add a new functionto the MTD interface
that will read/write only free OOB bytes as a single chunk of data.
Each of the options implies the need to extend ioctl interface to get
oobavail/oob free data.
Any comments are welcome.
More information about the linux-mtd