marty fouts wrote:
> Based on experience developing for PalmOS, and Linux on ARM devices
> and now learning my way around DangerOS, a few observations:
>
> NOR and NAND flash don't really fit the same abstraction. I think
> there's a lot of unnecessary overhead in Linux-MTD because it tries to
> be all things to all flash. I'd suggest being careful trying to
> abstract to bridge both.
>   

Ah, but unless someone wants to tackle NAND separately I'm not going to
do it.  NOR is more relevant to me at the moment.  I'd rather have a
common framework though, that someone else can extend to include NAND,
than two totally different frameworks.  It should be possible, IMO.

> There's a signficant tradeoff as to where you do the bad block
> management, block remapping, and garbage collecting.  If you put it in
> the filesystem, then you limit yourself to only file systems that know
> about the flash related issues.  This means that you get a lot of
> reinvention done as each new file system is adapted to using the
> device.
>   

A common filesystem should be able to deal with this.   This btw, is why
things like ufs know about physical characteristics to lay out the data
best for rotational delays on drives, etc.  By doing it this way you
give maximum flexibility at the filesystem later to do the right thing,
while possibly allowing for less code sharing between filesystems.  But
realistically, how many flash filesystems are we going to need?  In the
same system at once?

> While there are some performance disadvantages, I believe that such a
> system really needs an intermediate layer that provides a logical
> block device interface to the file systems and handles bad block
> management, et cetera.
>
> for nand flash, the standard operations seem to be:
> configure/get configuration
> read/write in-band/out-of-band
> ecc
> and
> erase region
>
> There are two approaches one can take, either treating the out-of-band
> region as separate and using two file descriptors, or handle the
> out-of-band read/write with ioctls.  I have no opinion on which is
> prefered.  I assume the config, ecc, and erase stuff would be handled
> via ioctl.
>   

NOR has no OOB.  I don't want an approach that is only useful to NAND. 
In fact, NOR is *more* important to me than NAND at the moment.

> There aren't any standard partitioning schemes for "MTD" devices.
> uboot and redboot each deal with paritioning differently, for example,
> which is why the Linux MTD layer has mapping.
>   

Which is why I've proposed leaving that MD bit in device properties,
which MD code can populate as appropriate (perhaps calling shared
redboot parser or something.)

> There are, I think, three ways to go about file systems for such
> devices, once they've got an interface in place:
>
> 1) (Most of the commercial NAND FSes do this) put most of the smarts
> in the block device layer and put an ordinary fs about that. (Bonus
> points for adding transaction-like capabilities.)
>   

A reasonable approach perhaps.  But it seems like the FS could perform
better if it new more about the underlying device.  The trade-off is
then that the FS needs to be able to learn and use that data.  I don't
think this is too much too ask.

> 2) The jffs approach: understand the limitations of the hardware and
> embed a lot of knowledge into the FS data structures, but avoid the
> out-of-band regions.
>   

This is necessary for use with NOR.

> 3) The yaffs approach: like jffs but use the out-of-band regions for
> the extra data.
>   

NOR doesn't have OOB regions like NAND does.

> Yaffs allows you to be more clever about how you use the device, but
> is subject to changes in the nature of the out-of-band area. jffs is
> currently slow. hopefully jffs3 will fix that.
>   

Yaffs is only useful to NAND, and not under consideration (by me at
least) at the moment.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191