Re: pf(4) status in 7.0-R

In message <86wsyhjo6n.fsf_at_dwp.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr
ites:

>> Dag-Erling Sm=C3=B8rgrav <des_at_des.no> writes:

>> > Convenient and portable, but buggy as hell - we used it in Varnish to
>> > begin with but had to ditch it due to a combination of design flaws and
>> > bugs.  It also suffers from creeping featuritis - the latest version
>> > includes a DNS resolver and a full HTTP implementation...  it's only a
>> > matter of time before it grows a lisp interpreter and a mail reader.

>> hmmm ... okay, didn't know that.  But what do you suggest as an
>> alternative?  I certainly won't reinvent the wheel for the libevent
>> calls in ftp-proxy.  Importing libevent code private to ftp-proxy
>> seems equally wrong.  So the alternatives - to me at least - are
>> either importing libevent or leaveing ftp-proxy in ports.  Pick your
>> poison.
>
>I suggest importing libevent (or a subset of it) as an internal library,
>i.e. define INTERNALLIB in the Makefile so we get a libevent.a which
>ftp-proxy can link against but which isn't installed.  Alternatively, we
>can import a subset of libevent and name it something else (like we did
>with expat -> bsdxml)

I have worked with event libraries extensively for the last five years
and I can only nod vigorously in agreement.

The Provos libevent is an undesigned kludge and it grows more kludges
all the time.  It should not be exposed or documented in FreeBSD,
but merely included only as a component if any bits need it.

The named eventlibrary is in much better shape, it has a well thought
out API (although I would have done some things differently) but
it is possibly not as performance tuned as it can be.

It is not as thread-friendly as we should require at this date and time.

If, and that is a strong IFF, we want to include a general purpose
event library in FreeBSD *right now*, the one from named is our
best bet at this point, and we have quite a lot of code which could
be significantly simplified that way, inetd is merely one obvious
example.

If we want to provide a high quality event library for present and
future needs, somebody needs to sit down and write that.

But in either case, an eventlibrary should not be imported, unless
we have code that uses it, and unless we intend to maintain it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.