From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22223 invoked by alias); 11 Jul 2005 10:47:52 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 21889 invoked by uid 22791); 11 Jul 2005 10:47:46 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 10:47:46 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 6F79565C082; Mon, 11 Jul 2005 11:47:44 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 04D4B65C07D; Mon, 11 Jul 2005 11:47:40 +0100 (BST) To: nickg@ecoscentric.com Cc: ecos-discuss@ecos.sourceware.org In-reply-to: (message from Nick Garnett on 11 Jul 2005 09:16:21 +0100) From: Bart Veer References: Message-Id: <20050711104740.04D4B65C07D@smtp.ecoscentric.com> Date: Mon, 11 Jul 2005 10:47:00 -0000 Subject: Re: [ECOS] Mutex & Asserts during initialisation X-SW-Source: 2005-07/txt/msg00104.txt.bz2 >>>>> "Nick" == Nick Garnett writes: >> I can see the other side of this. You want to write a driver >> that can work in a multi-threaded environment, so you include a >> mutex in it. But then you want to call it from startup code. >> Rather than write a second specialized non-multi-threaded >> driver, or include some sort of flag that tells it to skip the >> locking and unlocking, it's much cleaner to simply consider the >> attempt to lock a mutex before the threading system has been >> initialized a harmless null operation. Nick> And this is exactly what happens. The kernel installs the Nick> idle thread as the current thread as soon as it is Nick> initialized so that mutexes and semaphores will operate Nick> correctly before the scheduler starts. Nick> However, device drivers are usually initialized before this Nick> point, on the assumption that the hardware should be Nick> initialized as early as possible. Wallclock devices are Nick> initialized a little later, but still before the idle Nick> thread. Nick> The driver initialization priority was set long before these Nick> layered I2C and SPI drivers were introduced. These are a Nick> fairly new feature, and there are clearly a few teething Nick> troubles. Nick> I suspect that the correct fix for this problem is to move Nick> the initialization of the DS1307 to after the idle thread in Nick> initialized. The simplest way of doing this is to make all Nick> wallclock devices use CYG_INIT_IO priority. I agree this is the right short-term solution. In the medium or long term we may want to rethink the predefined constructor priorities. The current order is not necessarily optimal, and I would like to see a few more categories. It is a hard problem with lots of potential for circular dependencies and destabilizing existing systems, so I need to think about it for a while before coming up with a proposal. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss