From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9823 invoked by alias); 14 May 2009 18:41:21 -0000 Received: (qmail 9814 invoked by uid 22791); 14 May 2009 18:41:19 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_45,J_CHICKENPOX_93 X-Spam-Check-By: sourceware.org Received: from smtp-vbr9.xs4all.nl (HELO smtp-vbr9.xs4all.nl) (194.109.24.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 May 2009 18:41:14 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4EIe2GG014142; Thu, 14 May 2009 20:40:02 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A0C6674.5030006@cs.vu.nl> Date: Thu, 14 May 2009 18:41:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ross Younger CC: ecos-maintainers@ecos.sourceware.org, Simon Kallweit , Sergei Gavrikov , Melanie Rieback , Paul Beskeen Subject: Re: NAND & YAFFS References: <4A0AD212.60208@ecoscentric.com> In-Reply-To: <4A0AD212.60208@ecoscentric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00011.txt.bz2 Well, it is certainly time for me to voice my reaction to this news; sorry for the delay, caused by slow communication with my direct boss (on the CC:) because she is currently at the opposite side of the globe (and parental leave days). My employer (the VU Amsterdam, i.c. Prof. Andrew Tanenbaum's group) and the funder of our project had me spend 2..3 months in designing and making a NAND flash package from scratch plus an interface layer for YAFFS, with the explicit side-goal of contributing something substantial to the open-source community, i.c. eCos. I dutifully followed eCos' outlined procedures to avoid double work, and did RFCs and notification of early release (including the statement that it is complete on my BlackFin hardware, and that it had survived some long YAFFS tests). Sure, I picked up the comments made by Andrew Lunn. Allow me to confess that I am disappointed that the work I put into NAND flash for eCos has not been considered by eCosPro. The main reason they give is that it is in alpha state, and that my time line was unknown. I think that it would have been entirely possible and very much appropriate if eCosPro had asked me about stability and about my timeline. These questions for sure wouldn't have harmed confidentiality. The answer to the questions would have been: I say it is in alpha state because features that cannot be tested on my hardware are actually untested: e.g. the small-page chip instruction set or multiple, heterogeneous controllers/chips. My package has been stress-tested on my hardware, both NAND- and YAFFS-wise; it has been ported by Televic.be to their platform, and I am proud to report that no bugs came out even though their controller and ECC are entirely different (except for one thingy in a debug check, where my precautions to cover against YAFFS's unaligned struct fields proved insufficient). Another reason that I think eCosPro has not chosen the wisest course here is the shadow it throws into the future. Isn't it an unattractive proposition for anyone who would want to contribute that they will only afterwards be informed that their work may be out-competed by eCosPro themselves? So, the current state is that there are two NAND flash packages, both of which are complete and tested as far as their developer's hardware allows: single controller and single NAND chip. Work on YAFFS interfacing is complete and stress-tested (me) or nearing completion (eCosPro). Kind regards, Rutger Hofman VU Amsterdam Ross Younger wrote: > Dear maintainers, > > We (eCosCentric) have been working on a NAND layer for eCos and integration > with YAFFS, which we intend to contribute. Unfortunately, due to commercial > considerations - including licensing and technical discussions with Aleph > One - we have previously had to keep quiet about it. We can now talk about > this work publicly, and would like to explore how the best overall solution > for the eCos project can be pulled together. > > Obviously two alternative implementations and further duplication of work is > best avoided, so we have opened a discussion with Rutger to see if there are > ways in which we can work together to try and find a common "best of breed" > technical solution. > > It seems sensible that the maintainers are aware of this discussion and have > the opportunity to provide input and direction. > > A quick overview of our status: > > * We have developed a NAND interface library, drivers for a single > chip+board combination and a synthetic pseudo-device, and an adaptation > layer to bring YAFFS into eCos via the fileio layer. Specific further > support for RedBoot is also in the works. > * The NAND layer is complete and fully documented; YAFFS integration is > approaching completion. > * Written testcases exist for the NAND layer and YAFFS, and they will be > subject to the same rigorous in-house automated test processes we use for > all eCosPro code. > * All of our code is intended to be contributed back to eCos, except of > course the GPL parts of YAFFS itself. We have included in our plan building > YAFFS as a separate .epk file so users who are happy with the GPL can easily > download it and install using ecosadmin.tcl. > > We had looked at Rutger's early work, but decided against using it. Part of > the reason for this was that integrating alpha code from other sources is > always difficult, and we were (still are) operating under commercial time > pressures. It would have been difficult for us to go public before now > without sounding like we were taking advantage of Rutger's work, or > compromising the project's earlier need for confidentiality. There were also > some technical considerations; our NAND library has fewer layers, and our > YAFFS integration is subtly different. > > Please let me know your thoughts. I can provide an interim documentation or > code drop if you'd like to see one. (The NAND layer is complete; YAFFS is > still being worked on, and RedBoot will be next.) > > Regards, > > > Ross >