Subject: Re: MTD devices in NetBSD
To: Simon Burge <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/22/2006 16:17:19
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.
> Simon Burge <email@example.com>
> NetBSD Support and Service: http://www.wasabisystems.com/
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191