Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jun 2017 03:52:58 -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:  <063A0C56-E9D5-4C84-AD15-B36F267F00BA@dsl-only.net>
In-Reply-To: <20170617102407.GD2088@kib.kiev.ua>
References:  <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> <20170617102407.GD2088@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2017-Jun-17, at 3:24 AM, Konstantin Belousov <kostikbel@gmail.com> =
wrote:

> 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:
>>=20
>>> 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.
>>=20
>> Thanks for letting me know --and good to know.
>>=20
>> 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.

Sorry. I apparently read too much of my=20
overall purpose into your reply to what
I asked about for if the types needed to
be changed in fsread.c .


I've reported the "I never said that"
in 220024. I've also copied and pasted
your original reply for reference.

Again: Sorry to have misrepresented you.

=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?063A0C56-E9D5-4C84-AD15-B36F267F00BA>