Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Apr 2024 21:53:06 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Colin Percival <cperciva@tarsnap.com>
Cc:        Lexi Winter <lexi@le-fay.org>, arch@freebsd.org
Subject:   Re: enable INVARIANT_SUPPORT in GENERIC in release builds
Message-ID:  <CANCZdfr6TBCja6eD8MD7MxZN3N_NwVzpU8KzszqukO2yNFrMNg@mail.gmail.com>
In-Reply-To: <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com>
References:  <Zh7m7yKbNKafuU0J@ilythia.eden.le-fay.org> <0100018ee9e8a381-2e0a8845-5321-4841-bfaf-184376e88112-000000@email.amazonses.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000081b52d061642cba9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 16, 2024 at 8:35=E2=80=AFPM Colin Percival <cperciva@tarsnap.co=
m> wrote:

> 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 o=
n
> > 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.
>

I thought it had no overhead (despite the comments saying it does). It
only increases runtime from what I can see if INVARIANTS or WITNESS
are defined.


> > 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.  Of course we can't turn it on for
> stable/1[34] for the ABI reasons you just mentioned
>

I think that it just exports more functions, so that's something that could
be exported.

Warner

--00000000000081b52d061642cba9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 16, 2024 at 8:35=E2=80=AF=
PM Colin Percival &lt;<a href=3D"mailto:cperciva@tarsnap.com">cperciva@tars=
nap.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">On 4/16/24 14:00, Lexi Winter wrote:<br>
&gt; currently release version of GENERIC (or GENERIC-NODEBUG in main) does=
<br>
&gt; not have INVARIANT_SUPPORT enabled.<br>
&gt; <br>
&gt; unfortunately, the presence or absense of this option breaks the KABI<=
br>
&gt; because, as i understand it, modules built with INVARIANTS won&#39;t l=
oad on<br>
&gt; a kernel without INVARIANT_SUPPORT.<br>
&gt; <br>
&gt; is there a reason INVARIANT_SUPPORT can&#39;t just be enabled by defau=
lt?<br>
<br>
I think while it had much lower overhead than INVARIANTS, there was still<b=
r>
a significant overhead cost at least in the early days.=C2=A0 Maybe that&#3=
9;s no<br>
longer the case.<br></blockquote><div><br></div><div>I thought it had no ov=
erhead (despite the comments saying it does). It</div><div>only increases r=
untime from what I can see if INVARIANTS or WITNESS</div><div>are defined.<=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
&gt; this would remove one roadblock to separating kernel modules from the<=
br>
&gt; kernel config in both pkgbase and ports, because there would be no nee=
d<br>
&gt; to build a KABI-incompatible kernel just to build a single module with=
<br>
&gt; INVARIANTS.<br>
<br>
If the overhead cost of INVARIANT_SUPPORT is no longer relevant, I&#39;d be=
<br>
fine with including it in stable/15.=C2=A0 Of course we can&#39;t turn it o=
n for<br>
stable/1[34] for the ABI reasons you just mentioned<br></blockquote><div><b=
r></div><div>I think that it just exports more functions, so that&#39;s som=
ething that could be exported.</div><div><br></div><div>Warner <br></div></=
div></div>

--00000000000081b52d061642cba9--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr6TBCja6eD8MD7MxZN3N_NwVzpU8KzszqukO2yNFrMNg>