Date: Sat, 14 Feb 2026 10:47:45 +0100 From: Olivier Certner <olce@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 07c4eb506be4 - main - sys/compat/freebsd32: Fix i386 compilation Message-ID: <2406567.sMrx5ctUpN@ravel> In-Reply-To: <aZAHY8hVS52LEoQc@kib.kiev.ua> References: <698fa41b.23016.79a6cf2d@gitrepo.freebsd.org> <aZAF-qKQ5Z1P3-8x@kib.kiev.ua> <aZAHY8hVS52LEoQc@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > > 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmmQRMEACgkQjKEwQJce JifNfA//WzYQdEe6TdYVmwK5P/HZo7+2gInZWj8lPGv0I8n9/pv/ndQNi2p8mSNf IQ2s1Aqe7QOGmzz3ZQV0r6MNtOaN14eXKcBtRnKbB63nSR8JTt/Wr0MtttWWNrZ+ HSZKUcU38K9A0gbO8vksuhaFV9OKe0gYvHfOfYB8Rd0+q5LkJvHK52hTm6dlHQFT svrkJN3JS3vlBjmSM6pCOCjqNLhdYDitEal6u/7nqm3PX02fipcyAjzkUq5Yj20y y0LxztcFTjSxN1nNK2cCSvYhsZwv16wOtfxvwT9Lc/Uz2MRBgJu9HL9T6a9ozKXt gEkvKHIJ60jnznVxeKBleZxGRdw3SbrzpqjIEf1MUqWhUaV+sxnzvOhgJxFGchfc m28pA9YzWKPmbvJPHhp+716RaFiWulSj6k82x4yADNdNTSiRZKHVVOvQHguSJVL8 Rn+VfDf9+9nVlGzGmSD9Cc3QlLtaBzTd01heVXi+XGG5lGiY05EogzPdjkZOU//J l1z5LQcKSizN8UCLKDuqxDcCf5WO398un2btWrCVKuoTEH5EUCaJhzrZZOMv1qO1 jNwC4IBmPRTcnlFVCxS3nTSWsiL7RQ11AmPJT6vsO0BFAK7Q5CTC3XRCO3SsKz+7 FffTfEzHU6tJJofMrUazKcyML181mdBve4cMtP62ssn4FTDY7+Q= =JQ5Z -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2406567.sMrx5ctUpN>