> 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. > 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. 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. > 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. > what matters is the ability to create policies that will graph > how a packet traverses functional blocks. indeed an important issue, but this doesn't invalidate the previous. I guess we just have a different focus. > In regards to streams: Perhaps you should check why the folks at Sun are > migrating away from it. good point, thanks. Isn't it in there only for backward compatibility? Willem ps: I won't read my email for the next 8 hours (you can guess the reason). But if anyone has remarks, thanks. I'll answer tomorrow. - 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
