> Linux TCP/IP doesn't work like this.
I never said it did, I said that *functional frameworks* worked like this. For
the most part I believe Linux TCP/IP does work like this, though. I'll skip
routing when making this point.
Although Linux has indirect function calls to choose between a TCP and a RAW
protocol handler at a certain moment (or for dev_hard_start_xmit, ...), this
selection step itself is statically coded. You cannot decide to add a step in
between. Which is exactly what STREAMS gives. Whether that's necessary is a
different question.
> Linux netfilter is basically like STREAMS, so you're just showing
> that one STREAM like thing can be faster than another. Undoubtedly
> a full hardcoded filter system could be faster.
netfilter is far from the entire networking path in Linux. Anything related to
getting data up to userspace, or to/from device drivers is developed outside
of the netfilter framework. For example, NAPI or mmap patches. This is the
area that I am developing for, coming from a packet filtering background.
> So you want to replace something that you're not familiar with?
> That sounds like a upside down approach. How about studying prior art first
> to avoid making their mistakes and reusing their strengths?
I should have looked at netfilter if that was what I wanted to replace. Which
it wasn't (and isn't). However, you are right in the fact that there's
unfortunately overlap between the two systems.
Anyway, the same holds for SILK. Neither that nor FFPF are development
systems, but research. Mine is on pushing data up to applications in more
flexible ways than through sockets (and faster).
> > One advantage
> > is that a new netfilter function can be inserted in the stream if the
> > module is loaded. In a purely functional framework this would be
> > impossible, as all functions have to be known in advance.
>
> Your lack of knowledge about netfilter shows very clearly here.
Again, I never stated that netfilter is a purely functional framework.
Although my lack of netfilter indeed is unfortunate, it is of no direct
concern.
> Have you ever tried reading through the Linux routing code path? It
> doesn't sound like it.
have I ever mentioned the routing code path? That I omitted it in my answer to
John was, however, indeed a mistake. My apologies for that; you get a bit
shortsighted after looking at the same small domain for months.
That said, I had to compare to STREAMS, which was created for
kernel/application interaction. It was originally an alternative to sockets,
not to {pf, netfilter, click}, if I recall correctly. Bashing me for not
knowing routing is therefore a bit off-topic I believe.
Willem
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
