From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11137 invoked by alias); 7 Jun 2007 10:01:28 -0000 Received: (qmail 11083 invoked by uid 22791); 7 Jun 2007 10:01:26 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-34.mail.demon.net (HELO anchor-post-34.mail.demon.net) (194.217.242.92) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Jun 2007 10:01:19 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1HwEns-000ESh-Fm; Thu, 07 Jun 2007 10:01:17 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 0DDA913870A; Thu, 7 Jun 2007 11:01:16 +0100 (BST) To: "Mike Sweeney" Cc: ecos-discuss@ecos.sourceware.org References: <70d4f620706062016s593a05aen95aebfdad3f4ecf@mail.gmail.com> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Thu, 07 Jun 2007 15:11:00 -0000 In-Reply-To: <70d4f620706062016s593a05aen95aebfdad3f4ecf@mail.gmail.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question X-SW-Source: 2007-06/txt/msg00082.txt.bz2 "Mike Sweeney" writes: > I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is > intended to do. The reference manual for eCos says that it is used if > the interrupt controller requires you to acknowledge an interrupt. The > reason I am confused is that an interrupt service routine for a device > may need to clear a status flag in a peripheral status register even > if there is no interrupt controller. Is the intent that each interrupt > service routine handle this clearing of the flag in the peripheral > status register on its own, in addition to calling > HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with > the interrupt controller? It seems this is the case, but why is there > this special function in the HAL for handling the interrupt controller > acknowledgement? Why isn't this just handled directly by each device's > interrupt service routine without going through this interface? > > The hal_clock_reset() function makes it quite clear to me that each > ISR handles any status flags itself, because this is the only way the > ISR for the real time clock could be made generic as it is in the > kernel by calling hal_clock_reset() in addition to calling > HAL_INTERRUPT_ACKNOWLEDGE(). There are several reasons for this: 1. Abstraction. The author of a device driver should only need to concern himself with the details of the device, not with the details of the interrupt controller too. Acknowledgement is abstracted for the same reason masking and configuring the interrupts are also abstracted; the same reason we have HALs, a kernel, libraries and subsystems: division of responsibility into well defined layers. 2. Maintenance. If the way the interrupt controller is used needs to be changed, or a bug is found, it need only be changed in one place, and one doesn't have to search through all the device drivers for random bits of code. 3. Portability. Some device drivers are portable: many of the ethernet drivers, 16550 serial driver, CAN, USB etc. These drivers cannot contain code for all the possible platforms they may run on; platform-specific operations need to be handled in a portable way. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss