Date: Sat, 17 Jun 2017 13:24:07 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Millard <markmi@dsl-only.net> 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: <20170617102407.GD2088@kib.kiev.ua> In-Reply-To: <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: > 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: > >> . . . > > > > UFS uses 32bit inodes, changing to 64bit is both pointless currently, and > > causes on-disk layout incompatibilities. > > > > 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. > > > > 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 .) I never said that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170617102407.GD2088>