> in that case i misunderstood - your example seems to be talking about > functional packet processing "nodes" and how you connect them in a > graph. At least thats where the streams connotation seems to have come > in. And again my take is the fundamental ability to specify instances of > those nodes and the policy graphs that bind them is nothing new.
true, it's not new. The reason I ended up with it was purely practical and even grew out of a single-module system. Streams fitted our use-case, which is to run code in userspace, kernelspace and on the network-card. Communicating across 3 environments breaks function-calling as a viable method -- e.g., from context-switching. It can be used as a method to implement stream hand-off within the kernel, ofcourse. > In Linux there are a lot of practical issues that stop us from being > the theoretical perfect (like running Java instead). This might be the answer to John's question. Streams is supposedly a well-designed architecture, but relatively slow because of this(*). Linux networking gives a well-known API to the outside world, but everything below is purely built for practicality, and thus less formally defined. (*) one problem with streams-like abstractions is that they don't fit the real world al that well. For example, IP and TCP handling cannot easily be separated, since TCP needs to look at IP headers again. In extremis you end up with 1 big functional module again. John: Have a look at the xKernel for some pros and cons of streams. I forgot to mention that before. In the meantime I'll read through the netfilter sourcecode :) cheers, 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
