On Mon, 2006-16-01 at 00:05 +0100, Willem de Bruijn wrote: > > Well, if you are doing research you need to know whats out there so > > you can a) learn from it b) avoid reinventing the wheel > > That speaks for itself. I'm not completely ignorant and have read most that > has been published at decent venues. Thing is, I don't find such publications > about innovative features in netfilter. > > Don't get me wrong, I don't mean to be disrespectful (certainly not here :). > It is undoubtedly a very good production system, with novel extensions (e.g., > tc/u32) and looking through the source has been on my TODO list for a while. > But never on top. From doing so you might learn implementational details, I > honestly don't see how it will teach anyone entirely new techniques. >
It is not to teach you new techniques. It is more for you to understand whats out there before you start waving flags. As an academic, this is important to you, no? > > and more importantly so you can be honest and show the differences. > > Otherwise you are blaspheming. > > I don't think you meant what you said here. Even if it where a verb. > You misunderstood - I meant that in the scheme of things this is what one oughta follow else they are blaspheming; it is not accusing you of blasphemy (yet). > About being dishonest: I made it clear what my background was, that I didn't > know netfilter all that well, but knew it wasn't purely functional and that > others should chip in to tell me where I was wrong. Frankly, the reactions > startle me a bit: they appear to be more about the messenger than about the > contents. > Your message is what is being shot at and you may be a little too sensitive. Lets be constructive and not discuss your feelings. > > It doesnt matter whether the packet is coming into the system and > > leaving after some forwarding decision or whether it is going to user > > space- > > Here we disagree. With userspace/kernelspace you get additional costs, > context-switching and copying, that you want to avoid. Same for network > card/kernel boundary. This is exactly the focus of my work.: merging > data-access (mmap, ioremap), polling (napi/select()/poll()), and > hardware-assist in a single framework. > 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. In Linux there are a lot of practical issues that stop us from being the theoretical perfect (like running Java instead). cheers, jamal - 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
