This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: Jürgen Lambrecht <J dot Lambrecht at televic dot com>
- Cc: Ross Younger <wry at ecoscentric dot com>, Jonathan Larmour <jifl at jifvik dot org>, eCos developers <ecos-devel at ecos dot sourceware dot org>, Deroo Stijn <S dot Deroo at televic dot com>
- Date: Wed, 07 Oct 2009 18:31:37 +0200
- Subject: Re: NAND technical review
- References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com>
Jürgen Lambrecht wrote:
Ross Younger wrote:
Jonathan Larmour wrote:
[snip]
Is it possible that R's model follows better the "general" structure of
drivers in eCos?
I mean: (I follow our CVS, could maybe differ from the final commit of
Rutger to eCos)
1. with the low-level chip-specific code in /devs
(devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and
devs/flash/micron/nand)
2. with the "middleware" in /io (io/flash_nand/current/src and there
/anc, /chip, /controller)
3. with the high-level code in /fs
As far as I know, this has been the case for some releases already.
Is it correct that R's abstraction makes it possible to add partitioning
easily?
(because that is an interesting feature of E's implementation)
I think it would not be hard to add. It might involve a change in API
though, which is no problem as long as the number of clients is small,
and all the more when those clients desire it.
Rutger