Re: git: 07c4eb506be4 - main - sys/compat/freebsd32: Fix i386 compilation

> > So this is probably the wrong direction, it is not going to scale.
> If it is for i386 kernel, then even more we should just guard its usage
> with LP64 (__SIZEOF_LONG__ == 8 in modern parlance).
> Trying to make COMPAT32 valid for 32bit host is not sustainable.

Yes, that's for i386 kernel compilation.

I'm not trying to make the whole of COMPAT_FREEBSD32 valid on 32-bit platforms (that does not make any sense to me).

But since there are uses of 'freebsd32.h' unconditionally on all platforms (in 'kern_umtx.c' at least), and since we also check sizes of structures, I think we should at least ensure that 'struct foo32' on a 32-bit arch is type compatible with 'struct foo' on the same arch.

And I do not see that as unsustainable, on the contrary, it is very simple to achieve: Have all 'foo32' types boil down to exactly 'foo' on 32-bit architectures, which is what we are supposed to do already for structures by compat' design.  'freebsd32_uint64_t' you introduced typically supports that.  That's the why of https://reviews.freebsd.org/D55283, which fixes commit 87632ddf67b0 ("openzfs sys/types32.h: use abi_compat.h for time32_t") where defining 'time32_t' to 'in32_t' for 32-bit architectures appears to have been an arbitrary choice of yours, which in practice by luck does not change the whole size of 'struct ffclock_estimate32' because 'struct bintime32''s one does not change either as even if its field 'sec' was incorrectly sized after you commit (this is what D55283 fixes), the 'frac' one is 64-bit and 64-bit aligned on all non-x86 architectures so its offset in 'struct bintime32' stays the same.

So, again, I think the rule of thumb should just be: Type 'foo32' is compatible with 'foo' on 32-bit architectures and has same alignment.  That's the only thing that makes sense if 'struct *32' are visible on 32-bit architectures.

That does not impair the alternative, which is to remove visibility of all 'struct *32' on 32-bit architectures.  If you want to do that, please go ahead.

Regards.

-- 
Olivier Certner