From owner-freebsd-hackers@freebsd.org Sat Jun 17 03:54:13 2017 Return-Path: Delivered-To: freebsd-hackers@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 DE6B7BEE23C for ; Sat, 17 Jun 2017 03:54:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 777147D4C2 for ; Sat, 17 Jun 2017 03:54:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26687 invoked from network); 17 Jun 2017 03:55:37 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Jun 2017 03:55:37 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 16 Jun 2017 23:54:11 -0400 (EDT) Received: (qmail 16225 invoked from network); 17 Jun 2017 03:54:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jun 2017 03:54:11 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CF334EC8A8B; Fri, 16 Jun 2017 20:54:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? From: Mark Millard In-Reply-To: <20170617024850.GB2088@kib.kiev.ua> Date: Fri, 16 Jun 2017 20:54:10 -0700 Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 03:54:14 -0000 On 2017-Jun-16, at 7:48 PM, Konstantin Belousov = wrote: > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: >> . . . >=20 > UFS uses 32bit inodes, changing to 64bit is both pointless currently, = and > causes on-disk layout incompatibilities. >=20 > As a consequence, use of ino_t (64bit) or uint32_t for inode numbers = are > almost always interchangeable, unless used for specifying on-disk = layout. > UFS correctly uses (and was changed to use) uint32_t for inode numbers > in the disk-layout definitions. Other places, which calculate inode > numbers from inode block numbers, or do some other calculations with > inodes, are fine with either width. >=20 > That is, I believe that all instances which I looked at during the > ino64 preparation are fine. Thanks for letting me know --and good to know. I've added a note to the bugzilla report of the failed linking of boot1.elf for powerpc and powerpc64 that you have indicated that if the __udivdi3 is supplied to allow the linking to complete for builds based on clang then the result should operate okay for the mix of types. (The report is bugzilla 220024 .) =3D=3D=3D Mark Millard markmi at dsl-only.net