Date: Tue, 16 Dec 2025 13:24:17 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: kp@freebsd.org, ks@freebsd.org Cc: freebsd-pf@freebsd.org Subject: IFT_PFLOG and IFT_PFSYNC Message-ID: <aUHOAePgxI1nJhCq@cell.glebi.us>
index | next in thread | raw e-mail
Hi, the IFT_PFLOG and IFT_PFSYNC are the very last interface types remaining that should not exist :) I mean should not exist in the interface namespace of course! Historically, there was a long tradition to create a new interface type for whatever is not a network interface. This tradition comes from OpenBSD, but we have had our own sins, like IFT_USB for usbdump(8). Usually, the interface was created merely for ifp->if_bpf, like USB, ipfwlog and pflog. Another reason was lazyness (I speculate here) to implement a configuration path via ioctl(). When you create an interface, you just tunnel all configuration into ifp->if_ioctl() and this way you separate your code from in_control() that historically was very entangled in *BSD. I speculate that carp(4) and pfsync(4) were implemented as interfaces exactly for this reason. There is no urgency, but it would be nice to de-ifnet the pflog(4) and pfsync(4) in the 16.0-CURRENT timeline. For the pflog(4) it is going to be super easy, see how ddf4f9eda9c2 did that for ipfw(4). For the pfsync(4) the implementation shouldn't be difficult as well, however the difficult part is preserving user experience, so that machines boot with obsolete rc.conf. Good news is that we have /etc/rc.d/pfsync and supposedly nobody has bare ifconfig_pffsync0="" in their rc.conf. Again, no urgency, but something to think about. -- Gleb Smirnoffhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aUHOAePgxI1nJhCq>