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                                     

Reply via email to