All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Harald Welte <laforge@gnumonks.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	Jin-Sung Yang <jsgood.yang@samsung.com>,
	Ilho Lee <ilho215.lee@samsung.com>,
	Marc Zyngier <marc.zyngier@tomtom.com>,
	linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC] extending nand_ecclayout.eccpos once again
Date: Tue, 08 Sep 2009 09:13:35 +0300	[thread overview]
Message-ID: <1252390415.5060.38.camel@localhost> (raw)
In-Reply-To: <20090902093045.GB7377@prithivi.gnumonks.org>

On Wed, 2009-09-02 at 18:30 +0900, Harald Welte wrote:
> Hi!
> 
> There are large page size (4k) NAND chips + corresponding controller that use
> quite a lot of ECC, more than the traditional 48 bytes.
> 
> Specifically, at a 4kB page size and a 8bit ECC, there is a ECC layout
> that uses 104 bytes ECC
> 
> Now the problem is that nand_ecclayout uses a static array of 64 entries,
> and it is part of the MTD ABI to userspace.  simply changing 64 to a bigger
> number will not do.
> 
> I am proposing something along the lines of the following patch, i.e.  add a
> new 'nand_ecclayout2' structure (plus corresponding ioctl).  Unfortunately
> this means that all the drivers also need to rename that structure now.
> 
> However, we cannot simply keep the old name and modify, since that again
> breaks the ABI.
> 
> I'm increasing the size to 1024 bytes, hopefully that will be enough for
> a long time.
> 
> Please provide some feedback on what you think, or ideas for different
> approahces to implement this.
> 
> [pleaes note that this patch is not tested, it's simply to be used for
>  discussion how to proceed. Once there is a decision, I'll provide
>  the final/tested patch together with a ecclayout structure that actually
>  usese this]

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?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2009-09-08  6:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  9:30 [RFC] extending nand_ecclayout.eccpos once again Harald Welte
2009-09-08  6:13 ` Artem Bityutskiy [this message]
2009-09-08 15:28   ` Jamie Lokier
2009-09-08 17:26     ` Nicolas Pitre
2009-09-09 11:13       ` Harald Welte
2009-09-09 11:56         ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1252390415.5060.38.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ilho215.lee@samsung.com \
    --cc=jsgood.yang@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=laforge@gnumonks.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marc.zyngier@tomtom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.