From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1947 invoked by alias); 18 Nov 2008 17:59:57 -0000 Received: (qmail 1842 invoked by uid 22791); 18 Nov 2008 17:59:56 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Nov 2008 17:59:05 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E415F208030; Tue, 18 Nov 2008 17:59:02 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzqhXA0UTObn; Tue, 18 Nov 2008 17:59:02 +0000 (GMT) Received: from delenn.bartv.net (hagrid.vpn.ecoscentric.com [192.168.145.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 99EAA3B40069; Tue, 18 Nov 2008 17:59:00 +0000 (GMT) Date: Tue, 18 Nov 2008 17:59:00 -0000 Message-Id: From: Bart Veer To: Jonathan Larmour CC: ecos-devel@ecos.sourceware.org, ecos-maintainers@ecos.sourceware.org In-reply-to: <4922F997.8010408@eCosCentric.com> (message from Jonathan Larmour on Tue, 18 Nov 2008 17:21:27 +0000) Subject: Re: [flashv2 merge] io/flash References: <4922125E.9070308@eCosCentric.com> <49222917.8020407@eCosCentric.com> <4922E622.5070906@eCosCentric.com> <4922F997.8010408@eCosCentric.com> 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: 2008-11/txt/msg00005.txt.bz2 >>>>> "Jifl" == Jonathan Larmour writes: Jifl> I think this is all absolutely fine. >> Actually, it is wrong in at least one place. I remember one >> board where the CAN interface was hanging off an SPI bus >> instead of being on-chip. That implies CAN should be treated as >> a network device, not a bus, and should init at >> CYG_INIT_DEV_CHAR. >> >> Everybody, please think carefully about any funny boards you >> have come across over the years, and whether or not the above >> order makes sense. Jifl> Of course the purpose of having these numbers abstracted is Jifl> that if we do need to, it can be tweaked. Yes and no. Tweaking the numbers at any time in the future runs the risk of breaking existing ports. If we are going to make the change now then I hope we can get the order as close to perfect as possible. Although the amount of code affected is fairly small, the potential impact on existing ports is large. Any changes in this area would be new and have not had extensive testing in eCosCentric's testfarm. >> >> Finally the file I/O subsystem. Possibly this should happen >> >> earlier, between DEV_BLOCK_PRIMARY and CONFIG, so that an >> >> implementation of the config data module can be layered on top >> >> of file I/O. Or possibly CYG_INIT_IO_FS should happen >> >> immediately after CYG_INIT_MEMALLOC, with the proviso that file >> >> I/O operations for devices may fail until later in the init >> >> sequence. Jifl> It's certainly plausible to want to read config data from an Jifl> FS, IMHO. But CYG_INIT_MEMALLOC seems unnecessarily early Jifl> and would probably cause more problems than it solves. >> I am not sure I agree with that. MEMALLOC should only involve main >> memory, with no need to worry about whether or not any of the I/O >> subsystem is available yet. Initializing MEMALLOC early means that >> device drivers could perform run-time detection and dynamically >> allocate any buffers required, instead of statically allocating for >> the worst case. Jifl> I thought you were saying the order would be Jifl> CYG_INIT_MEMALLOC, CYG_INIT_IO_FS and then the rest of the Jifl> CYG_INIT_IO*. I don't have any issue with MEMALLOC being Jifl> first, but wouldn't have thought that CYG_INIT_IO_FS being Jifl> before CYG_INIT_IO* would work well. Jifl> Were you saying something differnt perhaps? Sorry, misunderstanding. OK, MEMALLOC happens before any I/O. As to CYG_INIT_IO_FS, the question is really what that is for. The main use right now is in io/fileio to initialize the various mutex locks, although there are some other uses in that package. Initializing mutexes and the file descriptor table early on should be harmless, but I am not familiar enough with the internals of the file I/O package to understand all the implications. Allowing the config code to mount a file system on top of a primary block device and then open and read a file obviously makes sense. It is not obvious that it makes sense to allow open() and read() before any primary block devices are initialized, but on the other hand it avoids problems if we ever add something ahead of primary block devices. There are also uses of CYG_INIT_IO_FS in the vnc_server and httpd packages. Those should probably get initialized a lot later. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071.