From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11488 invoked by alias); 30 Jun 2008 08:48:53 -0000 Received: (qmail 11410 invoked by uid 22791); 30 Jun 2008 08:48:53 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jun 2008 08:48:34 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1KDF3m-0007ad-00; Mon, 30 Jun 2008 10:48:30 +0200 Date: Mon, 30 Jun 2008 08:48:00 -0000 From: Andrew Lunn To: Davy Wouters Cc: ecos-devel@ecos.sourceware.org Subject: Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem Message-ID: <20080630084830.GB21756@lunn.ch> References: <111ced750806270740k430d9ca9we3f3f1bd84d65ab7@mail.gmail.com> <20080627182456.GH696@lunn.ch> <111ced750806300126v5ccc8120rcfa3cb106e891920@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111ced750806300126v5ccc8120rcfa3cb106e891920@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2008-06/txt/msg00042.txt.bz2 > The DSR mechanism has nothing to do with processor specific interrupt > handling but more with the eCos kernel internal stuff, correct? > In that case what is the exact role of the DSR in eCos? When to > implement one or not in a device driver? ISR can run any time interrupts are enabled. There is very little you can actually do in ISR context, just read/write bits in the hardware, generally you just disable the interrupt source. The ISR handler cannot do anything with the eCos scheduler. DSR will only run when the eCos scheduler is in a consistent state, i.e. the scheduler is not locked. DSR are allowed to do none blocking calls, eg signal a semaphore to wake up a thread etc. > I'm asking this because I thought that the DSR needed to be executed > after returning from the interrupt (reti or what ever), which is not > the case, in order to allow other interrupts > at this point. I thought that when combining ISR and DSR in one > interrupt handling of the processor, this would take too long and > deteriorate real-time behaviour? Your ISR and DSR handlers should not do any activities which take a long time, since while ISR & DSR are running, threads are not running. If you do need to do a lot of work it is much better to have a thread doing it, so the scheduler can pre-empty it for a higher priority thread. The TCP/IP stack follows this model. The Ethernet device drivers have a thread doing the actual copy of the packet from the hardware to the stack and the stack is run in a thread. Andrew