From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23086 invoked by alias); 7 Oct 2009 16:27:43 -0000 Received: (qmail 23078 invoked by uid 22791); 7 Oct 2009 16:27:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr7.xs4all.nl (HELO smtp-vbr7.xs4all.nl) (194.109.24.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Oct 2009 16:27:38 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id n97GRRIG032356; Wed, 7 Oct 2009 18:27:28 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4ACCC269.4020709@cs.vu.nl> Date: Wed, 07 Oct 2009 16:27:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= CC: Ross Younger , Jonathan Larmour , eCos developers , Deroo Stijn Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> In-Reply-To: <4ACC61F0.3020303@televic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00006.txt.bz2 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