On 19 Oct 2023, at 15:56, Kristof Provost <k...@freebsd.org> wrote: > > On 19 Oct 2023, at 16:41, Jessica Clarke wrote: >> On 19 Oct 2023, at 15:20, Kristof Provost <k...@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 <k...@freebsd.org> >>> AuthorDate: 2023-10-19 10:06:29 +0000 >>> Commit: Kristof Provost <k...@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
