public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Josh Boyer <jwboyer@gmail.com>
Cc: Vitaly Wool <vwool@ru.mvista.com>,
	William Watson <wjw1961@gmail.com>,
	yaffs@stoneboat.aleph1.co.uk,
	Charles Manning <manningc2@actrix.gen.nz>,
	linux-mtd@lists.infradead.org, tglx@linutronix.de
Subject: Re: [Yaffs] bit error rates --> a vendor speaks
Date: Tue, 21 Feb 2006 17:36:11 +0300	[thread overview]
Message-ID: <43FB255B.9050305@yandex.ru> (raw)
In-Reply-To: <625fc13d0602210550l69546064r5562b59d05af2a3c@mail.gmail.com>



Josh Boyer wrote:
> But Charles also wants clean interfaces.  I agree that clean
> interfaces are definitely a good thing, but trying to come up with a
> clean interface for OOB access that won't get bastardized seems to be
> unattainable.

But this does not mean that we should remove OOB support. Again, the 
right (IMO, of couse) way is to make several levels of generalization.

Just off the top of my head:

1. MTD level: a generic flash model with nothion of eraseblock, a 
mimimal I/O unit, read and write operations, nothing else. This level is 
for properly designed software.

2. NAND flash level: here you have OOB access. Work in terms of NAND 
pages, etc. Here YAFFS could be happy.

3. We could also have a DataFlash layer, where DataFlash guys could make 
use of their blocks and sectores, use features note visible from the 
topmost generic MTD layer.

> I think at some time in the not so distant future this whole
> conversation will become a moot point.  SLC NAND quality seems to be
> degradding as the die sizes go down, and MLC NAND is already of a
> degraded quality comparitively.  Better ECC algorithms will be needed
> to provide the reliability that people want and I can see that
> consuming all of the available OOB area anyway.

Still, the argument with CF cards makes me believe that vendors will 
provide some space for user data in OOB. Why can't they enlarge OOB size?

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

  reply	other threads:[~2006-02-21 14:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <43EB96DC.3030900@eptar.com>
     [not found] ` <35fb2e590602100558s2d868fa3o1752fbf3217439e4@mail.gmail.com>
     [not found]   ` <d97046180602151153g23064424x9e1ddf83a1d7ae4f@mail.gmail.com>
2006-02-16  1:32     ` [Yaffs] bit error rates --> a vendor speaks Charles Manning
2006-02-18  9:10       ` Thomas Gleixner
2006-02-18 16:31         ` Vitaly Wool
2006-02-19  8:22           ` Thomas Gleixner
2006-02-20 20:42             ` Charles Manning
2006-02-20 21:37               ` Thomas Gleixner
2006-02-20 22:40                 ` Charles Manning
2006-02-20 23:18                   ` Thomas Gleixner
2006-02-21  0:29                     ` Jon Masters
2006-02-21  8:26                       ` Thomas Gleixner
2006-02-21  9:35                         ` Jörn Engel
2006-02-21  1:08                     ` [Yaffs] bit error rates --> YAFFS for devices with no OOB Charles Manning
2006-02-21  2:12                       ` Jon Masters
2006-02-22  0:38                       ` Jamie Lokier
2006-02-21 12:14                   ` [Yaffs] bit error rates --> a vendor speaks Artem B. Bityutskiy
2006-02-21 13:50                     ` Josh Boyer
2006-02-21 14:36                       ` Artem B. Bityutskiy [this message]
2006-02-21 14:49                         ` Artem B. Bityutskiy
2006-02-21 11:59                 ` Artem B. Bityutskiy
2006-02-21 12:06                   ` Thomas Gleixner
2006-02-25 11:58                     ` Artem B. Bityutskiy
2006-02-27 13:27                       ` Josh Boyer
2006-02-27 16:01                         ` Artem B. Bityutskiy
2006-02-27 16:15                           ` Josh Boyer
2006-02-27 17:21                             ` Artem B. Bityutskiy
2006-02-27 17:40                               ` Josh Boyer
2006-02-18 18:11         ` Russ Dill
2006-02-19  0:29           ` Charles Manning
2006-02-19  5:08             ` Jon Masters
2006-02-19  8:29           ` Thomas Gleixner
2006-02-23  0:46             ` Russ Dill
2006-02-23  7:36               ` Thomas Gleixner
2006-02-23  8:31       ` Vitaly Wool
2006-02-24  9:51         ` Artem B. Bityutskiy

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=43FB255B.9050305@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=jwboyer@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manningc2@actrix.gen.nz \
    --cc=tglx@linutronix.de \
    --cc=vwool@ru.mvista.com \
    --cc=wjw1961@gmail.com \
    --cc=yaffs@stoneboat.aleph1.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox