Date: Fri, 16 Jun 2017 20:54:10 -0700 From: Mark Millard <markmi@dsl-only.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-hackers@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-ID: <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> In-Reply-To: <20170617024850.GB2088@kib.kiev.ua> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jun-16, at 7:48 PM, Konstantin Belousov <kostikbel at gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73F88E18-37A1-47C6-8783-F51F131A9671>