From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755964Ab0EQWUT (ORCPT ); Mon, 17 May 2010 18:20:19 -0400 Received: from terminus.zytor.com ([198.137.202.10]:38037 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751996Ab0EQWUQ (ORCPT ); Mon, 17 May 2010 18:20:16 -0400 Message-ID: <4BF1BF61.4030605@zytor.com> Date: Mon, 17 May 2010 15:12:49 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Benjamin Herrenschmidt CC: Yinghai , Ingo Molnar , Thomas Gleixner , Andrew Morton , David Miller , Linus Torvalds , Johannes Weiner , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH 01/35] lmb: prepare x86 to use lmb to replace early_res References: <1273796396-29649-1-git-send-email-yinghai@kernel.org> <1273796396-29649-2-git-send-email-yinghai@kernel.org> <1273803143.21352.353.camel@pasglop> <4BECEB8D.8070600@oracle.com> <1273824578.21352.579.camel@pasglop> <4BF18500.60105@zytor.com> <1274133749.21352.756.camel@pasglop> In-Reply-To: <1274133749.21352.756.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/17/2010 03:02 PM, Benjamin Herrenschmidt wrote: > On Mon, 2010-05-17 at 11:03 -0700, H. Peter Anvin wrote: >> On 05/14/2010 01:09 AM, Benjamin Herrenschmidt wrote: >>> >>> No. That is not the point. Read the rest of my email ! >>> >>> We need to -sanitize- those errors. _Maybe_ exposing LMB_ERROR is the >>> right way to do so, but in that case, we need to make -all- function use >>> the same error code. Right now, some fail with 0 and some with >>> LMB_ERROR. >>> >> >> Using errnos like the rest of the kernel seems like the right thing to >> do, IMO. > > Maybe. The allocator/find functions return a physical address. If we all > agree that a physical address between -PAGE_SIZE and 0 is never valid, > then we can overlay the negative errno codes like we do for pointers. > > I'll have a look at that, it shouldn't be very hard. > For x86 with 64-bit resource_t, this is always true (physical addresses are never negative.) For x86 with 32-bit resource_t negative physical addresses can be negative, but the top of the address space will always be occupied by the boot ROM (it's a hardware constraint.) -hpa