Hi, throwing in my two cents here, based on a few uneducated guesses reading the Makefile, etc. Feel free to disagree/correct/shout at me :)
(actually I wrote this before Willy answered) > As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would > require everyone that on a regular basis builds HAProxy with this > feature to change their build flags.. The name CONFIG_HAP_LINUX_TPROXY or USE_LINUX_TPROXY suggests this is for Linux. Implementing compatibility changes for FreeBSD in those flags is misleading, whether they are internal (like CONFIG_HAP_LINUX_TPROXY) or external (USE_LINUX_TPROXY). I think we should avoid that. > would require new make scripts and several other changes though-out where > transparent proxying is implemented. If you built haproxy before on FreeBSD and used transparent proxying, then it probably didn't work at all (like in your case) or those values have been defined in another place, like by libc or by a manual definition. Either way, we don't break anything that currently works by introducing a new build flag. So you would only have to adjust your make line if you actually need it and I think thats does less long-term harm than defining those things under the USE_LINUX_TPROXY/CONFIG_HAP_LINUX_TPROXY hat. > Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of > USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY > to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS. Yes, that makes more sense to me. We should probably clarify the condition with OpenBSD. I assume those defines are the same for all BSD flavors? So should we introduce a more generic flag like USE_BSD_TPROXY instead to avoid a USE flag for every BSD or does the difference between them justify a per-BSD USE flag? Regards, Lukas