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

From: Mark Millard <markmi_at_dsl-only.net> Date: Fri, 16 Jun 2017 20:54:10 -0700 · This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC

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 .)

===
Mark Millard
markmi at dsl-only.net