Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp <oliver@hartkopp.net>]

Patrick McHardy wrote:
> Urs Thuermann wrote:
>   
>> Patrick McHardy <kaber@trash.net> 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