Simon Burge wrote:
> "Garrett D'Amore" wrote:
>   
>> Simon Burge wrote:
>>     
>>> "Garrett D'Amore" wrote:
>>>
>>>       
>>>> 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.
>>>       
>> 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.
>>     
>
> A filesystem wouldn't directly attach to a bus - the filesystem will
> want a block device to talk to.  You then do your reads and writes and
> sector erase ioctls, etc to the block device.  To me, it's like the
> difference between "root on atabus0" vs "root on wd0".
>   

Ah.  See this is where we get hung up.  The idea is that historically
filesystems have needed to sit on top of a block device.  I'm not sure
this is the best abstraction for flash devices.

    -- Garrett
> Cheers,
> Simon.
> --
> Simon Burge                            <simonb@wasabisystems.com>
> NetBSD Support and Service:         http://www.wasabisystems.com/
>   


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