Subject: Re: MTD devices in NetBSD
To: Bill Studenmund <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 03/22/2006 09:55:24
Bill Studenmund wrote:
> 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.
>>>> 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 Interface,
>>>> 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 abstraction
>>>> 5. Implement "mtd" (block/char compat) driver on top of mtdbus
>>>> 6. Eventually, look at a rewrite of JFFS2 or YAFFS.
>>> 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.
I already commented on this. I think the bit is that the "mtd"
emulation device might not be necessary. I think you sort of make the
same point below.
>> 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
> 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.
Ah, but I don't want to do wear-leveling in the framework. That's the
purview of the filesystem, I think. I don't have a problem with
"mtdbus" becoming "flash". The "mtd" driver was just a layer that
exposed character/block operations to userland so that existing
filesystem code could use it.
> I guess the other thing I'm not sure of is how much of this you want to
> expose to userland. As you and others (say Allen) have noted, these things
> aren't normal devices. How hard _should_ we work to make them look normal?
I think there is a rational case for making it possible to mount, e.g. a
readonly ffs or iso9660 fs on a flash. To that end, block operations
are necessary. It can also help to have some of these operations
available during development. I don't think we should be encouraging
folks to use flash in a read/write mode this way, though, because I'm
not planning on on doing wear-leveling in the framework.
> 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
> leveling? If I understand wear-leveling right, the idea is that you expose
> a "device", and smear its blocks out around the real flash so that you
> don't burn holses in it; say you put a file system on top that always
> writes to block 10, you then do magic to move block 10 around as needed.
> How then do you know where to find block 10? Don't you really need some
> form of metadata to find the blocks?
See above. I think the filesystem is the right place to do this, not
> As a total aside, the proposal looks sound. The only main issue I found is
> one of semantics behind names youi chose. My lack of understanding of
> details regarding wear-leveling shouldn't hinder you. :-)
> So go for it.
> Take care,
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191