pf: remove DIOCGETSTATESNV

[kp]

Summary

While nvlists are very useful in maximising flexibility for future
extensions their performance is simply unacceptably bad for the
getstates feature, where we can easily want to export a million states
or more.

The DIOCGETSTATESNV call has been MFCd, but has not hit a release on any
branch, so we can still remove it everywhere.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

[mjg]

I don't know if it can be straight up removed in stable branches. Normally the expectation is that userspace can work with newer kernel, which is now broken.

Assuming it's not too much trouble, I think the thing to do first is to extend pfctl to support both interfaces and prefer the new one. Said binary compat can be then removed after few weeks.

[kp]

In D31099#699643, @mjg wrote:

I don't know if it can be straight up removed in stable branches. Normally the expectation is that userspace can work with newer kernel, which is now broken.

Assuming it's not too much trouble, I think the thing to do first is to extend pfctl to support both interfaces and prefer the new one. Said binary compat can be then removed after few weeks.

My plan was to push the preceding patches (i.e. adding and moving to the new call in libpfctl) first, and this one a week later. That'd give main and stable/X users some time to build a new kernel and userspace before we remove the old call. That achieves having the new kernel support old userspace, with a short transition period (so we don't end up with DIOCGETSTATESNV in a release and we have to support is forever).

[mjg]

that makes sense

[donner]

In D31099#699666, @kp wrote:

My plan was to push the preceding patches (i.e. adding and moving to the new call in libpfctl) first, and this one a week later. That'd give main and stable/X users some time to build a new kernel and userspace before we remove the old call. That achieves having the new kernel support old userspace, with a short transition period (so we don't end up with DIOCGETSTATESNV in a release and we have to support is forever).

A week is much to short for stable users.
Expect a month at least between updates.

[kp]

In D31099#699780, @donner wrote:

In D31099#699666, @kp wrote:

My plan was to push the preceding patches (i.e. adding and moving to the new call in libpfctl) first, and this one a week later. That'd give main and stable/X users some time to build a new kernel and userspace before we remove the old call. That achieves having the new kernel support old userspace, with a short transition period (so we don't end up with DIOCGETSTATESNV in a release and we have to support is forever).

A week is much to short for stable users.
Expect a month at least between updates.

I'm happy to postpone this commit for a month. As long as it goes in prior to the next release.