On 3/22/06, Garrett D'Amore <garrett_damore@tadpole.com> wrote:
> marty fouts wrote:
> > I'd recommend concentrating entirely on NOR and not worrying at all
> > about NAND then.
> >
> I'd rather not reinvent the wheel *twice*.  If NAND and NOR can be
> covered by the same abstraction, without significant loss of
> functionality or unusual complexity, then I'd prefer to do so.
>

And I'm arguing that MTD is a proof that they can't and shouldn't.=20
But an alternative implementation that works well would certainly shut
me up ;)

This isn't so much a case of reinventing the wheel as it is of trying
to get the same wheel to work on a mini and a semi

> > Almost inevitably you'll need at least two file systems: the one you
> > use internally and the one you put on removable flash media.
> >
>
> Okay, I meant how many *flash* filesystems do you need.

They're both flash file systems...

> I think its reasonable for the framework to expose and provide access to
> OOB.  The filesystem can choose whether or not to use it.

at least it's straight forward to do.  Don't make the mistake that MTD
makes wrt to placement of eccc in the OOB area and come up with a
cleaner abstraction for dealing with that and you might be on to
something.  (see the long discussions between Charles Manning and the
MTD folk on the yaffs mailing list for a history of the problem.)

> The fact that there is or isn't a filesystem there is irrelevant.  If
> you have a filesystem, it can do what it wants.  Other things that want
> raw access can do what they want.

Sorry, I wasn't making myself clear.  Something has to live above the
raw interface and deal with the same issues that the filesystem would
be dealing with, except it's not a file system.  Loaders need to know
about bad block management, for example.

You do end up putting much of the same knowledge in two different
places if you don't do an abstraction layer.

So far, we've gotten by with fairly simple stuff because we only deal
with bad block management and not wear leveling in loaders. Maybe
we'll be able to continue to get away with that.

> I'm not confident that I can come up with a universal answer to wear
> leveling and bad block mapping that doesn't include knowledge of the
> data being stored.  (For NAND, you could probably do this, because you
> always have OOB to stash away data.  You don't have that convenience for
> NOR.)

That's where device-level callbacks and plugability come into play.=20
You do a policy that's "good enough" for starters, figure out what
interfaces are needed to implement such a policy, and then make those
interfaces available as per-device-type hooks that allow the
implementor of a specific device to settle for 'good enough' or to
override with their own policy.

Certainly, an interface that exports the actual functionality will
always allow someone who comes later to do the layer I'm suggesting,
so it may well be something to defer.