Re: enable INVARIANT_SUPPORT in GENERIC in release builds
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 17 Apr 2024 05:38:10 UTC
[Just sending to the list this time, which also was missing.] On Apr 16, 2024, at 21:03, Mark Millard <marklmi@yahoo.com> wrote: [Just a resend fixing a Email address that I messed up.] On Apr 16, 2024, at 20:57, Mark Millard <marklmi@yahoo.com> wrote: Colin Percival <cperciva_at_tarsnap.com> wrote on Date: Wed, 17 Apr 2024 02:35:21 UTC : > On 4/16/24 14:00, Lexi Winter wrote: >> currently release version of GENERIC (or GENERIC-NODEBUG in main) does >> not have INVARIANT_SUPPORT enabled. >> >> unfortunately, the presence or absense of this option breaks the KABI >> because, as i understand it, modules built with INVARIANTS won't load on >> a kernel without INVARIANT_SUPPORT. >> >> is there a reason INVARIANT_SUPPORT can't just be enabled by default? > > I think while it had much lower overhead than INVARIANTS, there was still > a significant overhead cost at least in the early days. Maybe that's no > longer the case. > >> this would remove one roadblock to separating kernel modules from the >> kernel config in both pkgbase and ports, because there would be no need >> to build a KABI-incompatible kernel just to build a single module with >> INVARIANTS. > > If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I'd be > fine with including it in stable/15. I think the context here is intended to be more like (aarch64 example): https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-generic-nodebug-15.snap20240416014449.pkg with: https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-generic-nodebug-dbg-15.snap20240416014449.pkg These are from a release style build of main [so: 15] but via FreeBSD's own PkgBase distribution. # ls -C1 /boot/kernel*/kernel /boot/kernel.CA76-DBG/kernel /boot/kernel.CA76-NODBG.good/kernel /boot/kernel.CA76-NODBG.old/kernel /boot/kernel.CA76-NODBG/kernel /boot/kernel.GENERIC-DEBUG.good/kernel /boot/kernel.GENERIC-MMCCAM/kernel /boot/kernel.GENERIC-NODEBUG.good/kernel /boot/kernel.GENERIC-NODEBUG/kernel /boot/kernel/kernel The /boot/kernel.GENERIC-NODEBUG/ is from the likes of the above generic-nodebug-15 (but older). The /boot/kernel.CA76-*/ are my personal builds. (I'll not show where debug files go.) I was very happy to finally have official release of main to test for problem repeatability for release-style builds without my build(s) involved. Yea, I've also had rare examples where the likes of: https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-generic-15.snap20240416014449.pkg with: https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/FreeBSD-kernel-generic-dbg-15.snap20240416014449.pkg got differing behavior, including generic-nodebug-15 failing where generic-15 worked silently. Having INVARIANT_SUPPORT might mess up being able to check on official-release-style vs. personal-build distinctions as I've been doing. The /boot/kernel/kernel is from the likes of the above generic-15 (but older). [I do not really use /boot/kernel.GENERIC-MMCCAM/ (yet?).] I will note that I do not normally build modules that trace back to a port build being involved or the like: just what buildworld buildkernel sorts of activity build normally. I'm actively using such kernels, having installed the PkgBase ones and my own tailored build and picking which to use when. (I'm not claiming my usage pattern should drive what FreeBSD does.) > Of course we can't turn it on for > stable/1[34] for the ABI reasons you just mentioned. === Mark Millard marklmi at yahoo.com === Mark Millard marklmi at yahoo.com