Patrick McHardy wrote: > Urs Thuermann wrote: > >> Patrick McHardy <[EMAIL PROTECTED]> writes: >> >> >> >>> Is there a reason why you're still doing the "allocate n devices >>> on init" thing instead of using the rtnl_link API? >>> >> Sorry, it's simply a matter of time. We have been extremely busy with >> other projects and two presentations (mgmt, customers, and press) the >> last two weeks and have worked on the other changes this week. I'm >> sorry I haven't yet been able to look at your rtnl_link code close >> enough, but it's definitely on my todo list. Starting on Sunday I'll >> be on a business trip to .jp for a week, and I hope I get to it in >> that week, otherwise on return. >> > > > Sorry, but busy is no reason for merging code that has deprecated > (at least by me :)) behaviour. Please change this before submitting > for inclusion. >
Dear Patrick, i was just looking through the mailings regarding your suggested changes (e.g. in VLAN, DUMMY and IFB) an none of them currently went into the kernel and the discussion on some topics (especially in the VLAN case) is just running. I just got an impression of what you intend to have and it looks reasonable and good to me. But anyhow it's in process and therefore i won't like to be the first adopter as you might comprehend. It is no question, that we would update to your approach as it is part of the kernel, finalized in discussion and somewhat stable. But it doesn't look adequate to me to push us to support your brand new approach as some kind of gate for an inclusion into the mainstream kernel :-( So for me it looks like, that we should get the feedback from Jamal if our usage of skb->iif fits the intention of skb->iif and if we should set the incoming interface index ourselves of if we let netif_receive_skb() do this job. After that discussion i currently can not see any reason, why the PF_CAN support should not go into the mainstream kernel. I daily get positive community feedback about this matching implementation for the Linux kernel and it's elegant manner of usage for application programmers. On our TODO list there is the netlink support as well as the usage of hrtimers in our broadcast manager - but both have no vital influence to the new protocol family PF_CAN and therefore it should not slow down the inclusion process. Be sure that we'll support netlink immediately, when it hits the road for other drivers also. Best regards, Oliver - 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
