* Re: Large block NANDs - preliminary diff (2)
2004-03-26 16:13 ` Large block NANDs - preliminary diff (2) David Updegraff
@ 2004-03-27 7:52 ` Charles Manning
2004-03-27 9:05 ` Thomas Gleixner
1 sibling, 0 replies; 3+ messages in thread
From: Charles Manning @ 2004-03-27 7:52 UTC (permalink / raw)
To: David Updegraff, llandre; +Cc: linux-mtd
I agree with the concepts expressed here. Indeed, this is the approach I am
taking with YAFFS2.
-- CHarles
On Saturday 27 March 2004 04:13, David Updegraff wrote:
> llandre.
>
> Thanks for your work and patch. I may well be deluded, but aside from
> the large-page-inefficiencies vis.a.vis. file system allocations, it
> still seems to me we have some OOB troubles with the existing API.
> Because oob layout is exported, whereas I think oob layout should be
> hidden in the driver.
>
> From what I see, there are three reasons for anyone outside the driver
> to know about oob: ecc, badblock and fs-specific data.
>
> For ecc, they only need to set ON or off for the whole chip, for
> badblock its a boolean per page or block. And FSDATA is some stuff that
> the filesystem wants to scribble on its own, that the driver does not
> interpret.
>
> For ecc, there is already an ioctl that can set it generically, if you
> ignore the .eccpos bytes. And badblock also has a function pointer in
> the driver.
>
> What remains is a way for the filesystem drivers to scribble their own
> bytes of data per page or block. IMHO they should be able to do this
> independently. Perhaps that the officially PUBLISHED oobsize and
> oob_buf stuff currently in place should infact refer to those regions of
> the oob that are OUTSIDE of the internal-driver-managed oob regions
> dedicated to badblock marking or ecc tracking. The driver always does
> its own ecc calculations anyway: why even let anyone else see that area?
>
> But yes; I know; references to the oob stuff is sprinkled everywhere,
> and it'll probably be short-term easier to just add another case:
> here&there.
>
> -dbu.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Large block NANDs - preliminary diff (2)
2004-03-26 16:13 ` Large block NANDs - preliminary diff (2) David Updegraff
2004-03-27 7:52 ` Charles Manning
@ 2004-03-27 9:05 ` Thomas Gleixner
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Gleixner @ 2004-03-27 9:05 UTC (permalink / raw)
To: David Updegraff, llandre; +Cc: linux-mtd
On Friday 26 March 2004 17:13, David Updegraff wrote:
> llandre.
>
> Thanks for your work and patch. I may well be deluded, but aside from
> the large-page-inefficiencies vis.a.vis. file system allocations, it
> still seems to me we have some OOB troubles with the existing API.
> Because oob layout is exported, whereas I think oob layout should be
> hidden in the driver.
Never. Hiding stuff is evil.
The filesystem defines the OOB usage, as it stores filesystem dependend data
in the OOB area. So the filesystem gives the _generic_ nand driver the
information where the ECC is located in the OOB area.
JFFS2 and YAFFS have different OOB layouts. SMartMedi FAT has a own OOB layout
too. Do you want to change all this or allow the usage of only _ONE_
filesystem at a time ? I must be possible to have multiple filesystems on one
chip. We use YAFFS and JFFS2 on some boards. YAFFS for speed sake and JFFS2
to utilze on the fly data compression.
> From what I see, there are three reasons for anyone outside the driver
> to know about oob: ecc, badblock and fs-specific data.
>
> For ecc, they only need to set ON or off for the whole chip, for
> badblock its a boolean per page or block. And FSDATA is some stuff that
> the filesystem wants to scribble on its own, that the driver does not
> interpret.
> For ecc, there is already an ioctl that can set it generically, if you
> ignore the .eccpos bytes. And badblock also has a function pointer in
> the driver.
The userspace interface is neccecary if you want to write fs images to the
chip and utilize the ECC functions, especially if you have hardware ECC.
One other way to use it is for fs development and testing in userspace.
The badblock position must be exported to the fs driver, as it is located in
the OOB area.
> What remains is a way for the filesystem drivers to scribble their own
> bytes of data per page or block. IMHO they should be able to do this
> independently. Perhaps that the officially PUBLISHED oobsize and
> oob_buf stuff currently in place should infact refer to those regions of
> the oob that are OUTSIDE of the internal-driver-managed oob regions
> dedicated to badblock marking or ecc tracking. The driver always does
> its own ecc calculations anyway: why even let anyone else see that area?
Which area ? The ECC data is inside the OOB. The filesystem defines the OOB
layout and _MUST_ have access to the OOB area. Hiding things away is not a
real good idea, as it restricts the utilization of the device. Then we end up
exporting byte 1,2,6,9,14,15 as all other bytes are used by the nand driver.
This does not make any sense to me.
The filesystem provides an OOB buffer, which contains the data it wants to be
stored in the OOB area. The nand driver does the ECC calc and inserts the ECC
data into the OOB at the appropriate place. If we dont do it transparent then
we get byte 1,2,6,9,14,15 from the fs and have to build up a buffer for the
whole OOB stuff to insert ECC and write it to the device.
If the ECC positions are hardcoded in the nand driver each filesystem layer
_MUST_ use this layout. Depending on the information stored in the OOB area
the filesystem _MUST_ have the ability to define the ECC data positions. We
had hardcoded positions in the first versions of nand.c and we changed it to
allow different filesystems to use this driver and have their own OOB layot.
I don't see any real good reason to change the current interface. If somebody
comes up with a more efficient interface which has the same flexibility I'm
not in the way, but I doubt that there is one.
Don't tell me we should store the fs dependend layout in the nand driver.
Never. Nand driver controls nand chips and does not deal with fs specific
crap.
If you want to provide a new interface then do this considering the semantics,
that the filesystem handles the OOB contents and the nand driver provides a
mechanism to access it.
> But yes; I know; references to the oob stuff is sprinkled everywhere,
> and it'll probably be short-term easier to just add another case:
> here&there.
I dont see a way to use the OOB area for filesystem purposes without knowing
about it. Thats not a short term approach. It provides the flexibility to
develop new filesystems without changing the underlying basics.
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
^ permalink raw reply [flat|nested] 3+ messages in thread