From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3865 invoked by alias); 30 Mar 2007 08:59:39 -0000 Received: (qmail 3846 invoked by uid 22791); 30 Mar 2007 08:59:38 -0000 X-Spam-Check-By: sourceware.org Received: from atlantis.wh2.tu-dresden.de (HELO atlantis.wh2.tu-dresden.de) (141.30.228.39) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Mar 2007 09:59:36 +0100 Received: from [141.76.92.40] (unknown [141.76.92.40]) by atlantis.wh2.tu-dresden.de (Postfix) with ESMTP id E8B2BD3F59 for ; Fri, 30 Mar 2007 10:59:31 +0200 (CEST) From: Lars Poeschel To: "eCos Discussion" Date: Fri, 30 Mar 2007 09:23:00 -0000 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703301100.36190.larsi@wh2.tu-dresden.de> X-IsSubscribed: yes 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: [ECOS] RTC intr, context switch question X-SW-Source: 2007-03/txt/msg00179.txt.bz2 Hello! I am implementing context switch mechanism for fr30 architecture and maybe I did understand something wrong. My current interrupt handling is as follows: An interrupt causes a lookup in hal_vsr_table and a jump to the location read there (normally contains address of __default_interrupt_vsr). __default_interrupt_vsr then completly saves CPU context, and calls hal_interrupt_handlers[vector](vector, hal_interrupt_data[vector]). After that interrupt_end(return_val, hal_interrupt_objects[vector], regster_state) is called, once this returns, saved CPU state is restored and return to program happens. The kernel installs a scheduler_isr into the hal_interrupt _handlers, where HAL_THREAD_SWITCH_CONTEXT macro is called to switch from current to next thread. Is it right that HAL_THREAD_SWITCH_CONTEXT again saves CPU context to current threads stack ? Then I would have 2 contexts on stack and only one would be restored, because HAL_THREAD_SWITCH_CONTEXT immediately returns to next thread without using the rest of __default_interrupt_vsr where the context saved at the beginning of __default_interrupt_vsr is finnally restored. I think this is not the way it should work. Please point me to the right direction. Thanks, Lars -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss