Time to ask annoying questions.

On Tue, 21 Mar 2006, Garrett D'Amore wrote:

> Okay, I'm ready to start getting *serious* about supporting MTD (flash!)
> devices in NetBSD.
> 
> I've been doing a lot of research.   I want to sum it up here, along
> with my thoughts.  I'm *particularly* interested in what core@ has to
> say, so that perhaps we can move to actually implementing something
> "real".  I am aware that others are starting to work on this problem,
> but I think there is a lack of hard technical direction, and I think it
> is important to get the "framework" right:
> 
> MTD devices differ from regular "block" devices in some important aspects:
> 
>    1. you have to erase a block before you write it (read-modify-write
>       cycle)
>    2. They need wear-leveling (writes "wear" the bits out) to prolong
>       device life
>    3. Many NOR devices can map directly into system memory while in read
>       mode
>    4. Generally NAND devices cannot do this, and usually need special
>       handling
>    5. You may have to to do bad block management (some block devices
>       have to do this)
>    6. Generally, most filesystems designed for use with block devices
>       won't work so well
>    7. Some devices support "execute in place", while some do not
>    8. CompactFlash doesn't count, because it looks like an IDE disk. :-)

How does the above differ from `regular "block" devices'?

The erasure issue is only visible if you allow sub-block writes.  Is that 
something you're relly thinking about doing?  Is there any reason why you 
would want to leave a block erased without immediately writing useful data 
to it?

Wear leveling and bad block replacement have traditionally been filesystem 
issues since they deal with the layout of the data on the device.  (There 
once was a time when disks did not automagically do bad block replacement 
for you, and some of the code may still be in the source tree.)  In order 
to manage these features you will need to store data structures somewhere, 
which essentially means implementing the equivalent of a filesystem, 
whether you want to call it that or not.  You may want to investigate 
using layered filesystems to implement this rather than a device 
framework.  Layered filesystems can give more flexibility.

What operations do you think a flash memory device needs to support beyond 
the standard open(), close(), strategy(), and ioctl(), or for the 
character device, open(), close(), read(), write(), mmap(), and ioctl()?

Eduardo