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

[Mark Millard]

On 2017-Jun-17, at 3:24 AM, Konstantin Belousov  wrote:

> On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote:
>> On 2017-Jun-16, at 7:48 PM, Konstantin Belousov  
>> 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.

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.

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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Konstantin Belousov]

On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote:
> On 2017-Jun-16, at 7:48 PM, Konstantin Belousov  
> 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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

On 2017-Jun-16, at 7:48 PM, Konstantin Belousov  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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Konstantin Belousov]

On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote:
> buildworld via clang for powerpc64 and powerpc fails for lack of
> `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
> code. But this lead to me looking around and I found a conceptually
> separate possible issue. . .
> 
> sys/sys/_types.h :
> 
> typedef   __uint64_t  __ino_t;/* inode number */
> 
> # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more
> typedef __ino_t ino_t;
> /usr/src/sys/sys/stat.h
> typedef __ino_t ino_t;  /* inode number */
> /usr/src/sys/sys/types.h
> typedef __uint64_t  __ino_t;/* inode number */
> /usr/src/sys/sys/_types.h
> typedef __ino_t ino_t;
> /usr/src/sys/sys/dirent.h
> 
> 
> sys/boot/common/ufsread.c :
> 
> . . .
> #include 
> #include 
> #include 
> . . .
> typedef uint32_tufs_ino_t;
> . . .
> 
> Note the 32-bit type above. The headers included
> have use of the 64-bit ino_t type as well, for
> example:
> 
> sys/ufs/ufs/diniode.h :
> 
> . . .
> #define UFS_ROOTINO ((ino_t)2)
> . . .
> #define UFS_WINO((ino_t)1)
> . . .
> 
> sys/ufs/ffs/fs.h :
> 
> . . .
> #define ino_to_cg(fs, x)(((ino_t)(x)) / (fs)->fs_ipg)
> #define ino_to_fsba(fs, x)  \
> ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \
> (blkstofrags((fs), ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs))
> #define ino_to_fsbo(fs, x)  (((ino_t)(x)) % INOPB(fs))
> . . .
> 
> 
> I believe the powerpc64/powerpc issue
> gives evidence of ino_t being used in
> addition ot ufs_ino_t in
> sys/boot/common/ufsread.c 's fsread_size .
> 
> 
> Other things that look 32-bit inode-ish:
> (I do not claim to know that any of this
> matters.)
> 
> sys/ufs/ufs/dir.h has:
> 
> struct  direct {
> u_int32_t d_ino;/* inode number of entry */
> . . .
> struct dirtemplate {
> u_int32_t   dot_ino;
> . . .
> u_int32_t   dotdot_ino;
> . . .
> 
> struct odirtemplate {
> u_int32_t   dot_ino;
> . . .
> u_int32_t   dotdot_ino;
> . . .
> 
> 
> sys/ufs/ffs/fs.h has:
> 
> struct jrefrec {
> . . .
> uint32_tjr_ino;
> 
> struct jmvrec {
> . . .
> uint32_tjm_ino;
> 
> struct jblkrec {
> . . .
> uint32_tjb_ino;
> 
> struct jtrncrec {
> . . .
> uint32_tjt_ino;

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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

Top post of context note:

I should have noted up front that:

/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c

does:

#include "ufsread.c"

and that is the context of the __udivdi3
use that is rejected at link time when
clang is used to buildworld for powerpc
or pwoerpc64.

My original note might really trace back to
boot1.c needing to be different even if
ufsread.c stays the same.

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

On 2017-Jun-16, at 5:01 PM, Mark Millard  wrote:

buildworld via clang for powerpc64 and powerpc fails for lack of
`__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
code. But this lead to me looking around and I found a conceptually
separate possible issue. . .

sys/sys/_types.h :

typedef __uint64_t  __ino_t;/* inode number */

# find /usr/src/sys/ -exec grep __ino_t {} \; -print | more
typedef __ino_t ino_t;
/usr/src/sys/sys/stat.h
typedef __ino_t ino_t;  /* inode number */
/usr/src/sys/sys/types.h
typedef __uint64_t  __ino_t;/* inode number */
/usr/src/sys/sys/_types.h
typedef __ino_t ino_t;
/usr/src/sys/sys/dirent.h


sys/boot/common/ufsread.c :

. . .
#include 
#include 
#include 
. . .
typedef uint32_tufs_ino_t;
. . .

Note the 32-bit type above. The headers included
have use of the 64-bit ino_t type as well, for
example:

sys/ufs/ufs/diniode.h :

. . .
#define UFS_ROOTINO ((ino_t)2)
. . .
#define UFS_WINO((ino_t)1)
. . .

sys/ufs/ffs/fs.h :

. . .
#define ino_to_cg(fs, x)(((ino_t)(x)) / (fs)->fs_ipg)
#define ino_to_fsba(fs, x)  \
   ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \
   (blkstofrags((fs), ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs))
#define ino_to_fsbo(fs, x)  (((ino_t)(x)) % INOPB(fs))
. . .


I believe the powerpc64/powerpc issue
gives evidence of ino_t being used in
addition ot ufs_ino_t in
sys/boot/common/ufsread.c 's fsread_size .


Other things that look 32-bit inode-ish:
(I do not claim to know that any of this
matters.)

sys/ufs/ufs/dir.h has:

struct  direct {
   u_int32_t d_ino;/* inode number of entry */
. . .
struct dirtemplate {
   u_int32_t   dot_ino;
. . .
   u_int32_t   dotdot_ino;
. . .

struct odirtemplate {
   u_int32_t   dot_ino;
. . .
   u_int32_t   dotdot_ino;
. . .


sys/ufs/ffs/fs.h has:

struct jrefrec {
. . .
   uint32_tjr_ino;

struct jmvrec {
. . .
   uint32_tjm_ino;

struct jblkrec {
. . .
   uint32_tjb_ino;

struct jtrncrec {
. . .
   uint32_tjt_ino;



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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

buildworld via clang for powerpc64 and powerpc fails for lack of
`__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
code. But this lead to me looking around and I found a conceptually
separate possible issue. . .

sys/sys/_types.h :

typedef __uint64_t  __ino_t;/* inode number */

# find /usr/src/sys/ -exec grep __ino_t {} \; -print | more
typedef __ino_t ino_t;
/usr/src/sys/sys/stat.h
typedef __ino_t ino_t;  /* inode number */
/usr/src/sys/sys/types.h
typedef __uint64_t  __ino_t;/* inode number */
/usr/src/sys/sys/_types.h
typedef __ino_t ino_t;
/usr/src/sys/sys/dirent.h


sys/boot/common/ufsread.c :

. . .
#include 
#include 
#include 
. . .
typedef uint32_tufs_ino_t;
. . .

Note the 32-bit type above. The headers included
have use of the 64-bit ino_t type as well, for
example:

sys/ufs/ufs/diniode.h :

. . .
#define UFS_ROOTINO ((ino_t)2)
. . .
#define UFS_WINO((ino_t)1)
. . .

sys/ufs/ffs/fs.h :

. . .
#define ino_to_cg(fs, x)(((ino_t)(x)) / (fs)->fs_ipg)
#define ino_to_fsba(fs, x)  \
((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \
(blkstofrags((fs), ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs))
#define ino_to_fsbo(fs, x)  (((ino_t)(x)) % INOPB(fs))
. . .


I believe the powerpc64/powerpc issue
gives evidence of ino_t being used in
addition ot ufs_ino_t in
sys/boot/common/ufsread.c 's fsread_size .


Other things that look 32-bit inode-ish:
(I do not claim to know that any of this
matters.)

sys/ufs/ufs/dir.h has:

struct  direct {
u_int32_t d_ino;/* inode number of entry */
. . .
struct dirtemplate {
u_int32_t   dot_ino;
. . .
u_int32_t   dotdot_ino;
. . .

struct odirtemplate {
u_int32_t   dot_ino;
. . .
u_int32_t   dotdot_ino;
. . .


sys/ufs/ffs/fs.h has:

struct jrefrec {
. . .
uint32_tjr_ino;

struct jmvrec {
. . .
uint32_tjm_ino;

struct jblkrec {
. . .
uint32_tjb_ino;

struct jtrncrec {
. . .
uint32_tjt_ino;



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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"