On 2017-Jun-17, at 3:24 AM, Konstantin Belousov <kostik...@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>
>>> 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.
Sorry. I apparently read too much of my
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.
markmi at dsl-only.net
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"