From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 21:29:25 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39154106568D for ; Mon, 12 Oct 2009 21:29:25 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id D2CAE8FC20 for ; Mon, 12 Oct 2009 21:29:24 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9CLTHwX087997; Mon, 12 Oct 2009 16:29:17 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1255382957; bh=QugtbOQervTwVkdu2+8SdEUj1v2fwR6K3Dg4KgPGOJo=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=XLvFJ+oP2H6gO0QYOhPvFBz2FQhcSs9LGREE+tg1LTs2G/XV5DznTaUpMbmxcLmx4 cgi6pM4bcBK5sL+qDCXzUmc6QBvE8sLOAxX3Rdf+cs69uld6oE9pfkSikuo1CRtNn0 ElJFpHiKdc8D7GZrxwNiyoNvENeGi9NmMmLae0yY= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9CLTHsp087996; Mon, 12 Oct 2009 16:29:17 -0500 (CDT) (envelope-from tinguely) Date: Mon, 12 Oct 2009 16:29:17 -0500 (CDT) From: Mark Tinguely Message-Id: <200910122129.n9CLTHsp087996@casselton.net> To: freebsd-arm@freebsd.org, gballet@gmail.com, nwhitehorn@freebsd.org, stas@deglitch.com, tinguely@casselton.net In-Reply-To: Cc: Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 21:29:25 -0000 > As a result, extending the struct cpu_functions is not a good thing > either, for the same reason. The compiler can not inline a call > through a function pointer. > > In which case, why not create a bunch of headers files with the > pattern cpufunc_myarch.h, in which all functions would be declared > inline? Something like: > > static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > ... > which would then be included by pmap.c and friends. I think they need to be regular function calls because assembly routines call the per-cpu functions. A few simple macros would save the branch to NOP functions. > One problem is that such a change affects all platforms at the same > time, and therefore requires all portmeisters to implement the > functions that are needed. That should not be too difficult, though, > because so far it was the same macros that were used by all platforms. > Another problem is that it requires some build script magic to make > sure the correct header is included depending on the arch. I wonder if > this is easy? --Mark Tinguely