--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 22, 2006 at 08:17:54AM -0800, Garrett D'Amore wrote:
> Simon Burge wrote:
> > "Garrett D'Amore" wrote:
> >
> > First off, I think "MTD" is the name of the Linux flash subsystem, as
> > opposed to a general term used to describe flash devices.  I'd be more
> > tempted to just call it the "flash" driver.
> >  =20
>=20
> OK.
> >  =20
> >> Now, here's what I'm thinking:
> >>
> >>    1. Start with a definition of what ops an MTD must export, probably
> >>       following Linux in this regard
> >>    2. Implement MI NOR flash driver using "CFI" (Common Flash Interfac=
e,
> >>       found on many NOR ports)
> >>    3. Implement bus-specific stuff for one or more platforms.
> >>    4. Implement MTD stuff as an "mtdbus" for lack of a better abstract=
ion
> >>    5. Implement "mtd" (block/char compat) driver on top of mtdbus
> >>    6. Eventually, look at a rewrite of JFFS2 or YAFFS.
> >>    =20
> >
> > I think having an mtdbus in between the cfi driver and the final block
> > driver is just adding a level of indirection that isn't really needed in
> > this case.

I agree with Simon on this one.

> Okay, but I think the point is that you might not want to have code for
> a block device hanging around, particularly if you're going to use
> something like JFFS2 that can access the "mtdbus" directly.

??

You don't have to have an attach point in the device tree to have a way=20
that JFFS2 could access the device directly.

Hmm... There's something in the design here I don't like.

Actually, if you changed "mtdbus" to "flash" and turned "mtd" into
"wlevel" (or some other name for a wear-leveling driver) a lot of my
concern goes away. "mtdbus" really isn't a bus. :-) It is fine for
devices/sub-systems to attach to devices.

I guess the other thing I'm not sure of is how much of this you want to=20
expose to userland. As you and others (say Allen) have noted, these things=
=20
aren't normal devices. How hard _should_ we work to make them look normal?=
=20

I don't think I have the answer to the above question. :-)

So here's a question in return. How do you think we should do wear=20
leveling? If I understand wear-leveling right, the idea is that you expose=
=20
a "device", and smear its blocks out around the real flash so that you=20
don't burn holses in it; say you put a file system on top that always=20
writes to block 10, you then do magic to move block 10 around as needed.=20
How then do you know where to find block 10? Don't you really need some=20
form of metadata to find the blocks?


As a total aside, the proposal looks sound. The only main issue I found is=
=20
one of semantics behind names youi chose. My lack of understanding of=20
details regarding wear-leveling shouldn't hinder you. :-)

So go for it.

Take care,

Bill

--DocE+STaALJfprDB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEIYe1Wz+3JHUci9cRAo3wAJ9ef7VRxwA/BxwWO6oyA6w8e75P0wCfbzxr
CwYxO2LDTTgNPZ4QgqKsS+A=
=tF8t
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--