Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sat, 17 Jun 2017 13:24:07 +0300
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.
Received on Sat Jun 17 2017 - 08:24:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC