public inbox for linux-can@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Kurt Van Dijck <kurt.van.dijck@eia.be>
Cc: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: [RFC v4] CAN FD support
Date: Tue, 15 May 2012 17:51:20 +0200	[thread overview]
Message-ID: <4FB27B78.4070002@hartkopp.net> (raw)
In-Reply-To: <20120515135429.GB1414@vandijck-laurijssen.be>

On 15.05.2012 15:54, Kurt Van Dijck wrote:

> Oliver,
> 
> A few nitpicks, and 1 change of behaviour, as announced in my last reply
> on v3.
> 

> [...]
>> diff --git a/net/can/bcm.c b/net/can/bcm.c
>> index 151b773..98b5604 100644
>> --- a/net/can/bcm.c
>> +++ b/net/can/bcm.c
>> @@ -1357,6 +1357,13 @@ static int bcm_notifier(struct notifier_block *nb, unsigned long msg,
>>  
>>  	switch (msg) {
>>  
>> +	case NETDEV_CHANGEMTU:
>> +		/*
>> +		 * Changing the MTU breaks the frame size that was formerly
>> +		 * registered. The change can only be done when the interface
>> +		 * ist down. Btw. make sure to get no trash from the device and
> 'ist' sound german.
> You have this in several places :-)


Oh, snap! German engineering :-)

http://www.youtube.com/watch?v=0I0WfnhVs2s

Fixed the typo in my git repo.

>> +		 * drop this device from the open sockets perspective.
>> +		 */
>>  	case NETDEV_UNREGISTER:
>>  		lock_sock(sk);
>>  
>> diff --git a/net/can/raw.c b/net/can/raw.c
>> index cde1b4a..a20ee8e 100644
>> --- a/net/can/raw.c
>> +++ b/net/can/raw.c
> [...]
>> @@ -119,6 +120,14 @@ static void raw_rcv(struct sk_buff *oskb, void *data)
>>  	if (!ro->recv_own_msgs && oskb->sk == sk)
>>  		return;
>>  
>> +	/* do not pass frames with DLC > 8 to a legacy socket */
>> +	if (!ro->fd_frames) {
>> +		struct canfd_frame *cfd = (struct canfd_frame *)oskb->data;
>> +
>> +		if (unlikely(cfd->len > CAN_MAX_DLEN))
> idea:
> 			cfd->len = CAN_MAX_LEN;
> 
> but this modification must then be done _after_ the skb_clone below.


I dislike cutting payload data, because people would not be able to detect
that. It's better to provide nothing than to provide manipulated data.

It's hard for me to follow your argument that people will get confused when
they don't see a CANFD frame on a legacy RAW socket.

Up to then CANFD capable CAN tools will be surely available too.

>> +			/* return; */
>> +	}
>> +
>>  	/* clone the given skb to be able to enqueue it into the rcv queue */
>>  	skb = skb_clone(oskb, GFP_ATOMIC);
>>  	if (!skb)
>> @@ -246,6 +255,13 @@ static int raw_notifier(struct notifier_block *nb,
>>  
>>  	switch (msg) {
>>  
>> +	case NETDEV_CHANGEMTU:
>> +		/*
>> +		 * Changing the MTU breaks the frame size that was formerly
>> +		 * registered. The change can only be done when the interface
>> +		 * ist down. Btw. make sure to get no trash from the device and
>> +		 * drop this device from the open sockets perspective.
>> +		 */
> 
> why exactly?


The MTU can only be changed when the interface is down. But the registered CAN
device specific filters are not removed on interface DOWN/UP sequence.

Probably removing the registered filters is not so relevant anymore as we have
the simultaneous access for new/legacy apps now. Will think about it.

Regards,
Oliver

  reply	other threads:[~2012-05-15 15:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15 13:29 [RFC v4] CAN FD support Oliver Hartkopp
2012-05-15 13:54 ` Kurt Van Dijck
2012-05-15 15:51   ` Oliver Hartkopp [this message]
2012-05-15 18:48     ` Kurt Van Dijck
2012-05-15 20:33       ` Oliver Hartkopp
2012-05-15 21:16         ` vcan name Kurt Van Dijck
2012-05-16 12:38           ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB27B78.4070002@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=kurt.van.dijck@eia.be \
    --cc=linux-can@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox