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.
>>>   
>>>       
>> OK.
>>     
>>>   
>>>       
>>>> 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
the framework.

>
> 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. :-)
>   

Cool.

    -- Garrett
> So go for it.
>
> Take care,
>
> Bill
>   


-- 
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