From owner-svn-src-head@freebsd.org Thu Mar 3 15:20:23 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A46AA93B6A; Thu, 3 Mar 2016 15:20:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CDA0F51; Thu, 3 Mar 2016 15:20:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id c203so17165668oia.2; Thu, 03 Mar 2016 07:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2D2Yq4YUhoDLIrKU12Xc+I5/eXFKNjg7M0L6BGniCf8=; b=ePfCbiCggvJrU8VQdsed1DSMFYxl/XKmJOcKT3zXs7QqVGS9tmsK9+rpoKcTBPXzxu agYs0/WV93pGAr7HgFp/9sw43A+pf8JS1/eg7njNga7HQUyhqpLm6OCkbfqXcfgj0x2H CrSlVYlcDIE521YE8+BP8ouOY02miyUsVXOrHwzTdw6mne3B3pZXtd2UGDfHpJDOrRgQ J7Lr8EshRmK70X3//z8ewEkO5vHqqZrg7fkR6NuBaWhDWPxjRhl9v5P0UVpCKq3spQwy p/q/7JSn7atvK+DpsHosY3Q3W12CBcq9eWfn5CLo61jlCj/ZsGEwepQEGiMJUFBD719b tk2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2D2Yq4YUhoDLIrKU12Xc+I5/eXFKNjg7M0L6BGniCf8=; b=duWswKhVUOe7kM6iTW4ujemDjJt22nQf5nwE0mELrV8rWBXvduLfp1vOFT4mvARQNX aIwI5zR/YZwT8hv+Q83DpUu4dZQ2DHw3yt2hnnUspSlq+aXVKtda5Ql3oxscbsCbVHa2 jeXQN1no5rh7qpua0SRf8+gPRmdlC0+rXauFvMdiUcTa6AdXSYLgKfDAzEcXq1shxGNb LmSkW2ipqtd4D2Gp8F7h54M5QBzGgYdgncTuDZJAqGohyL44Q61VW3AWo3X9dC0DsFPi RDaztr+PCusSEzIf22u6nWMJVscsnvstbaUkJEzQkGiv+nBwpFN41rTujZBlFGni1NMW fYpA== X-Gm-Message-State: AD7BkJKk8JbeKeQw6yv/vNml/WV9b1k/1tphmLuJvM/Ilranop1Z479qCt+gchJqRWR1VFNqOITlkFz+ZFRj0g== MIME-Version: 1.0 X-Received: by 10.202.203.77 with SMTP id b74mr2139518oig.56.1457018422340; Thu, 03 Mar 2016 07:20:22 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Thu, 3 Mar 2016 07:20:22 -0800 (PST) In-Reply-To: <20160303164728.W1928@besplex.bde.org> References: <201603030507.u2357ae2098576@repo.freebsd.org> <20160303164728.W1928@besplex.bde.org> Date: Thu, 3 Mar 2016 09:20:22 -0600 X-Google-Sender-Auth: YqGSnFETOX-nDfSG0mC55Dzya4I Message-ID: Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen From: Justin Hibbits To: Bruce Evans Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:20:23 -0000 On Thu, Mar 3, 2016 at 12:18 AM, Bruce Evans wrote: > On Thu, 3 Mar 2016, Justin Hibbits wrote: > >> Log: >> Replace all resource occurrences of '0UL/~0UL' with '0/~0'. >> >> Summary: >> The idea behind this is '~0ul' is well-defined, and casting to uintmax_t, >> on a >> 32-bit platform, will leave the upper 32 bits as 0. The maximum range of >> a >> resource is 0xFFF.... (all bits of the full type set). By dropping the >> 'ul' >> suffix, C type promotion rules apply, and the sign extension of ~0 on 32 >> bit >> platforms gets it to a type-independent 'unsigned max'. > > > Why not use the correct signed value? This value is -1, not the value, if > any, with all bits 1. All bits 1 might be a trap representation, but it > is unclear if ~0 can give a trap representation or a trap since it is > unclear if the '~' operation acts on padding bits. It is clear that all > bits 1 gives has value -0 in 1's complement if there are no no padding > bits. But -0 has the same value as +0. When converted to an unsigned > type, it loses all traces of its sign, and becomes plain (ufoo_t)0. > > I don't like the plan to change the resource range type to uintmax_t. > 64 bits is just bloat for most 32-bit systems. After fixing all the > hard-coded u_longs, you can just use a typdefed type which should be > uint32_t if possible. > > Bruce The change to uintmax_t has been on the horizon since rman was first introduced in 1998. There is a comment (was in sys/sys/rman.h, now in sys/kern/subr_rman.c) regarding switching to unsigned long long to support 36-bit addressing on IA32. My selfish reasoning for taking on the work now is supporting 36-bit addressing for PowerPC, where device resources are located at physical addresses >4GB. Yes, it could be a machine dependent typedef, but what does that buy us in the grand scheme? The data overhead is not large -- an extra 8 bytes per resource (resource_i), plus 12 (maybe up to 20 depending on how much padding is added) per resource_list_entry. The code penalty is the added code to deal with using 2 registers (on RISC architectures) for each argument in resource related calls, plus the added math. But much of this will get lost in the noise anyway. Any runtime performance penalty is negligible, and only incurred at startup. After resource provisioning it's business as usual. ARMv7, PowerPC, i386, and MIPS32 all support 36-bit addresses. New PowerPC Book-E (e6500 core) supports 40-bit physical address, as does MIPS with XPA. uint32_t typedef would be relevant in only 2 cases: i386 non-PAE, and armv4 (3, if armv7 becomes a separate arch from armv6, but I doubt that'll happen). - Justin