Re: git: 9eff6390718d - main - pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h

On 19 Oct 2023, at 15:56, Kristof Provost <kp@FreeBSD.org> wrote:
> 
> On 19 Oct 2023, at 16:41, Jessica Clarke wrote:
>> On 19 Oct 2023, at 15:20, Kristof Provost <kp@FreeBSD.org> wrote:
>>> 
>>> The branch main has been updated by kp:
>>> 
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
>>> 
>>> commit 9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
>>> Author:     Kristof Provost <kp@FreeBSD.org>
>>> AuthorDate: 2023-10-19 10:06:29 +0000
>>> Commit:     Kristof Provost <kp@FreeBSD.org>
>>> CommitDate: 2023-10-19 14:19:39 +0000
>>> 
>>>   pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h
>>> 
>>>   When userspace includes pfvar.h it doesn't get the kernel's COMPAT_*
>>>   defines, so we end up not having required symbols in userspace. This
>>>   caused the libpfctl port to fail to build.
>>> 
>>>   libpfctl will be updated to use the new netlink-based state export code
>>>   soon, which will also fix thix build issue.
>>> 
>>>   Sponsored by:   Rubicon Communications, LLC ("Netgate")
>> 
>> That’s normally a feature to stop userspace using deprecated things.
>> Will you be reverting this once libpfctl is fixed? One could also hack
>> libpfctl instead to define COMPAT_FREEBSD14 temporarily (IIRC that’s
>> what was done for kbdcontrol to allow it to run on old kernels).
>> 
> I wasn’t planning on that, no. The libpfctl port fix should land soon, but I figured that it’d be better to keep the definitions, because userspace doesn’t know if the kernel is built with or without COMPAT_FREEBSD14.
> I’m open to being persuaded that that’s a bad idea though.

Indeed it doesn’t, because it shouldn’t. The thinking is that userspace
should *never* explicitly use them, only the kernel to provide
compatibility with binaries built against older versions. Deliberately
exposing them to userspace is quite unusual and deemed generally dodgy.

Jess

> Long-term (i.e. by freebsd 16) the plan is for all of these ioctls to go away (so the code for them will stay in 15, but not be in 16), but that does depend on me doing a fair bit of work before then.
> 
> Best regards,
> Kristof