From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18814 invoked by alias); 6 Jun 2005 08:50:56 -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 18767 invoked by uid 22791); 6 Jun 2005 08:50:46 -0000 Received: from ns2.nec.com.au (HELO ns2.nec.com.au) (147.76.180.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 06 Jun 2005 08:50:46 +0000 Received: from deer.dd.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id j568od6Q021072; Mon, 6 Jun 2005 18:50:39 +1000 Received: from dvalin.dd.nec.com.au ([172.31.20.70]) by deer.dd.nec.com.au (8.12.5/8.12.5/Debian-1) with ESMTP id j568odl0009645; Mon, 6 Jun 2005 18:50:39 +1000 Received: from dvalin.dd.nec.com.au (localhost [127.0.0.1]) by dvalin.dd.nec.com.au (8.12.3/8.12.3/Debian-5) with ESMTP id j568n8vl004692; Mon, 6 Jun 2005 18:49:08 +1000 Received: (from erik@localhost) by dvalin.dd.nec.com.au (8.12.3/8.12.3/Debian-5) id j568n6Zo004690; Mon, 6 Jun 2005 18:49:06 +1000 From: Erik Christiansen Date: Mon, 06 Jun 2005 08:50:00 -0000 To: Nick Garnett Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20050606084905.GA708@dd.nec.com.au> References: <20050603084643.GC716@dd.nec.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i Subject: Re: [ECOS] Disabling interrupts when locking the scheduler X-SW-Source: 2005-06/txt/msg00029.txt.bz2 On Fri, Jun 03, 2005 at 10:37:35AM +0100, Nick Garnett wrote: > Erik Christiansen writes: > > > > *1) No timeslicing, CYGSEM_HAL_USE_ROM_MONITOR == 1. > > Why do you want to do this? The reason is that we have configured eCos to leave interrupt handling to our pre-existing application, and initialised the interrupt vectors from our pre-existing BSP. There are then no DSRs. If interrupts are disabled while in the kernel, then it seems "in principle" safe for ISRs to directly employ the kernel API, and the lack of DSRs is no longer a problem. (Please accept my apologies for attempting such acts with eCos.) > eCos is carefully designed not to disable interrupts unnecessarily. Understood from the documentation. (And I'd like to have the time to go with that, but when porting an existing application, there can sometimes be strong imperatives to avoid a major rebuild.) We can tolerate a little interrupt latency. > It will probably fail catastrophically if interrupts are disabled > during the scheduler lock periods. > > The interrupt disable you have found is only part of the SMP code, and > is matched by a HAL_RESTORE_INTERRUPTS() at the end of the > HAL_SMP_SCHEDLOCK_INC() macro. So interrupts are disabled for a very > short period, inside that macro. Oh Oh! Yes, only disabling interrupts for the whole kapi function, not just during locking/unlocking, would give their use in an ISR any chance of success. (But I don't yet understand why the longer disable period is such a big risk.) Thank you for your analysis & warnings. We'll give it a shot, and see what happens. It's bound to teach me something. :-) Erik -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss