[RFC] extending nand_ecclayout.eccpos once again

[Harald Welte]

On Tue, Sep 08, 2009 at 01:26:20PM -0400, Nicolas Pitre wrote:
> On Tue, 8 Sep 2009, Jamie Lokier wrote:
> 
> > Artem Bityutskiy wrote:
> > > Can we instead assume that exposing ECC layout to user-space is jut bad
> > > idea, deprecate current layout ABI, and do not do this anymore.
> > > 
> > > I mean, really, ECC layout is generally not user's concern. Just do not
> > > expose it and problem is solved.
> > > 
> > > Is it absolutely necessary to have expose this stuff to user-space?
> 
> I admit having the same question from time to time.
> 
> > Let's rephrase that question.
> > What tools use this information?
> 
> Right.  And whether or not that tool is useful enough to warrant the 
> cost of maintening an interface to communicate that stuff from/to user 
> space.  I don't remember ever having to rely on that.

I have to agree with Artem, Jamie and you:  I personally don't think I've ever
used a tool that needs this interface, but I'll check.  The kernel source
actually contained a hint why it was exposed to userspace.

"ECC layout control structure. Exported to userspace for diagnosis and to allow
 creation of raw images"

I think the diagnosis is not really all that important (you can, after all,
look at the kernel source to determine the oob layout that is used)

Creating raw images?  I'm also not sure how often that is being done.  Why
would you precompute an image with ECC and then write that to NAND rather than
having the NAND layer generate the ECC while writing the image (like writing
any other data)?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)