From: "Caitlin Bestler" <[EMAIL PROTECTED]> Date: Wed, 26 Apr 2006 09:57:22 -0700
> The major element I liked about Kelly's approach is that the ring > is clearly designed to allow a NIC to place packets directly into > a ring that is directly accessible by the user. Evolutionary steps > are good, but isn't direct placement into a user-accessible simple > ring buffer the ultimate justification of netchannels? It is a very good point and one I actually need to think about some more. I'll be up front and say that I don't think it's actually necessary to do channels all the way to userspace, just channeling to the in-kernel networking protocol is more than sufficient. This will get us most of the way without having to deal with any of the thorny issues of doing protocols in userspace. I could be wrong but this is my gut instinct at this time. > Central integration also will need to be integrated with packet > filtering. In particular, once a flow has been assigned to a > netchannel ring, who is responsible for doing the packet filtering? > Or is it enough to check the packet filter when the net channel flow > is created? Very good question and one that hasn't been discussed enough yet. Eventually we should be able to do things such as allow netfilter to register channels too. Before we do that, we'll have to decide how we'll handle potential conflicts between local sockets and firewall rules. There is a school of opinion that would agree to a rule such as: if a local socket exists, it can trump firewalling. This would be a nice and simple way to deal with firewall rules that potentially shadow local sockets. You couldn't have created that fully bound socket in the first place if the firewall rules didn't allow it. You'd need to insert rules subsequently that block the connection's flow. If we want to support that we either have to do netfilter channels from the get-go, or simply disable socket netchannels altogether if netfilter is enabled. I personally think allowing sockets to trump firewall rules is an acceptable relaxation of the rules in order to simplify the implementation. - 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
