From: Jamal Hadi Salim <[EMAIL PROTECTED]> Date: Sun, 24 Jul 2005 21:49:34 -0400
> The semantics of the two are very different. real_dev is in regards to > stacked interfaces and input_dev is in reference to track what the last > ingress interface was. So it is ambigous to have them to be the same > thing. As an example, "redirecting from eth20 (which is not part of > bond0) to bond0" is not the same as "packet last seen on bond0 was > received on eth0 (which is part of bond0)" I think in the end it ends up being the same thing. And the current specific settings of input_dev has the following problems: 1) you cannot ingress classify on tunneling virtual devices, since ->input_dev only gets set for (some) hardware device types 2) not all hardware device types are supported, because we have to add specific settings of ->input_dev, which is just broken I have never ever seen one good argument for the way input_dev is set now, and your new response is no different. Why, for example, are hardware devices any different from virtual ones for ingress classification purposes? A clean generic interface would consider them the same and equally specifyable. Right? Every time a driver decapsulation happens (regardless of whether this is some hardware or virtual device), we have a new input device to classify upon. I don't see why you wish to continue breaking this logical representation. - 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
