Date: Mon, 29 Mar 2021 07:03:34 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Kristof Provost" <kp@FreeBSD.org> Cc: "FreeBSD pf" <freebsd-pf@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] pf ioctl changes Message-ID: <202103291403.12TE3Y2H094131@slippy.cwsent.com> In-Reply-To: <24E09373-EBCD-4ED1-8B59-A44E687F287E@FreeBSD.org> References: <24E09373-EBCD-4ED1-8B59-A44E687F287E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <24E09373-EBCD-4ED1-8B59-A44E687F287E@FreeBSD.org>, "Kristof Provost " writes: > Hi, > > There are several patches in the pipeline that require changes in pf’s > interface between kernel and userspace. > In the past these have been handled in multiple ways. Either by simply > making the change, breaking binary compatibility, or by introducing a v2 > ioctl (e.g. DIOCADDALTQV1). > > While one is better than the other neither is wholly satisfying. New > versions of calls constitute a maintenance burden after all. > > I’d like to change the ioctl interface to use nvlists, which would > make such extensions much easier, because fields can be optional. > That is, if userspace doesn’t supply the ‘shinynewfeature’ field > the kernel can assume the default value and things just work. Similarly, > if the kernel supplies a ’shinynewfeature’ which userspace doesn’t > know about it’s simply ignored. > > The rough plan is to introduce nvlist versions of the get/add rules > calls for now. Others will follow as the need presents itself. > As these are new ioctls it is safe to MFC them to stable/12 and > stable/13. > The old interface will remain supported in those branches, but I’d > like to remove it from main (and thus FreeBSD 14). > > As part of this effort I may end up splitting off the ioctl interface > code from pfctl into libpfctl, which should make reuse of that code > easier. > > I hope to post preliminary patches in the coming week. > > Thoughts? Objections? Kernel and userland should be, I'd say must be, kept in sync. We have many examples of userland and kernel not being in sync over the years. For ipfilter, I've made incompatible changes to data structures requiring userand and kernel be in sync. These are few and far between. I've gotten away with this because there is no third party software that relies on the ipfilter kernel interfaces. I could be wrong but I doubt there may be third party software requiring pf ABI compatibility. But if there is then verstioned library interfaces are required. Given that the advice is to keep kernel and userland in sync there probably is no requirement for an UPDATING entry but that would be your call. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202103291403.12TE3Y2H094131>