This is the mail archive of the
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.firstname.lastname@example.org> <4ACC61F0.email@example.com>
Jürgen Lambrecht wrote:
Ross Younger wrote:
Jonathan Larmour wrote:
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
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
(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.