On 16 Dec 2025, at 22:24, Gleb Smirnoff wrote:
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.
I’ll certainly keep it in mind, but my current priority in refactoring
work is to get the control plane converted to netlink. I’d hoped to
get that done before 15.0, but it’s still pretty far from complete
now.
I’m not strictly opposed to this, but I do worry a bit that it’s
going to confuse users, even if we have the scripts handle this.
Honestly, I’m not quite clear on how it’d all work myself.
Presumably we’d build something similar to pflowctl for pfsync,
pfsynctl, to set up and configure pfsync. That’s currently done
through ifconfig of course. A pretty inevitably user-visible change, but
probably manageable.
Pflog seems harder. There’s not much to configure, but exporting
information is done through `tcpdump -n -e -ttt -i pflog1`, which sort
of assumes a network interface.
Your ddf4f9eda9c2 change talks about a BPF tap ipfwlog0. Does that mean
we can `tcpdump -i ipfwlog0` even if there’s no struct ifnet ipfwlog0?
(I don’t have a machine running recent enough main to actually test
right now.)
That’d probably be fine, even if I’m sure doing `tcpdump -i pflog0`
is going to confuse me if ifconfig claims there’s no such interface as
pflog0.
Best regards,
Kristof
