> kuznet@ms2.inr.ac.ru <kuznet@ms2.inr.ac.ru> [Thu, Apr 03, 2003 at 02:23:44AM +0400]: >Hello! > >> > The patch adds rtmsg_pid and rtmsg_protocol fields to struct in6_rtmsg. >> > Additionally, it adds an rt6i_protocol field to struct rt6_info. Finally, >> > it adds a pid parameter to many of the functions in the IPv6 route add/ >> > delete callpath. <snip> >I do not think struct in6_rtmsg can be extended in this way, >it is user level struct and netlink pid is not going to propagate >beyond rtnetlink. > >So, I think the patch is not acceptable exactly in this form. Ok. >But it is important enough yet. > >I think right way is adding some new argument to functions using in6_rtmsg. >Right now I am not sure what it should look like, but necessary natural >precondition is that it must include all the RTA_* attributes, >which have no way to be controlled by user at the moment: mtu/mss are >the most important. It could be f.e. array of rtattr's. Well, and something >to pass protocol and pid. Original nlmsg? I considered the original nlsmg, but rejected it almost out of hand because I felt there must have been some reason that it wasn't passed along in the first place. If this would be acceptable solution for you, then I'll be happy to make the change. >Are you interested? Definitely, although I likely won't have an opportunity to work on changes to the patch until sometime next week. >If you are, let me to advise how not to do this. :-) >Look into ipv4, where adding intrakernel route is like nightmare, >because demanded attributes are mixed with rarely used ones and >caller have to prepare something complicated to add even >the simplest route. I'm very impressionable... I'm not sure how closely I should be looking at something I don't want to emulate ;) mrr - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
