Re: Patch: accept filters for NetBSD

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> [...accept filters...]
> You may very well want to make some connections go away without ever
> bothering userspace.  That almost always requires looking at the
> data.  [...] you have to peek into [the data]

As described upthread, feels kinda gross - it feels like the sort of
kludge I'd expect to find in Linux, not a BSD.  Data-present is not a
particularly useful test (connection floods just need to include a byte
of data), and moving part of HTTP into the kernel strikes me as
something that we might want to support via a general mechanism but not
via special-case code.

I would much rather see a small special-purpose language,
philosophically a la bpf's filtering language, which applications could
use to move a small and well-defined part of their early processing
into the kernel.  Perhaps provide a hooks to allow LKMs to do this kind
of thing, maybe even support compiling them in - but do it via a
general mechanism into which the HTTP (or whatever) support is plugged,
which is not what this sounds like so far.

I will readily admit I haven't yet had the opportunity to sit down and
read it over to see if that's how it's already structured; this is
based on the feel of the discussion, and noting that the first page or
two of the patch puts files in netinet/.  If it really is easily
pluggable, then it bothers me less, though I'd still prefer to see the
files somewhere more appropriate than netinet/ (for example, the HTTP
support belongs in webserver packages, not the main tree, ISTM).

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B