David, On Tue, Aug 01, 2006 at 05:35:35PM -0700, David Miller wrote: > This is partly why the multiple routing table code is being > added as the initial infrastrucutre, so that source based > things are possible.
There have been other approaches for partial source-based stuff. For instance, in my tree i brought Subtrees back to a point of being usable. But what i was refering to was route-caching (some places only check cookies based on dst because we "don't support source routing"), APIs, etc. A few mails back you pointed the extension of a public structure to include a "source" attribute -- this is the kind of stuff we must add and that i think it's an independent work (read: even if the rest isn't merged, this should). Still regarding Subtrees, is there any interest in revitalizing that code? I have a couple patches that i could submit. > Such a scheme would need provisions for handling the case where > the user eats the message, but never tells us what to do. > In such a case we'd need to emit some kind of ICMPv6 message, > even if it would be just a timeout generated parameter problem. As i see it, the moment there is a raw socket open for dealing with a particular protocol, whoever opened that socket (handling the protocol) is responsible of generating any error messages associated with the protocol running. Which is the case, the kernel shouldn't need to know whether any of the Mobile IPv6 specific messages have problems. The particular patch i was refering to does partial MIPv6 message processing inside the kernel before handing it to the socket as you only have access to the full received headers there. > Such a layer would be needed if we ever put some kernel level > components of Mobile IPv4 into the tree, which I see no reason > not to, since it has this route optimization as well. Yes, the functionality is needed. My only problem is with exposing MODE_ROUTEOPTIMIZATION, it isn't modular. But it's something i can live with. Hugo
signature.asc
Description: Digital signature
