netdev - Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Nov 2015 11:44:28 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Marek Vasut <marex@...x.de>
CC:	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
	Aleksander Morgado <aleksander@...ksander.es>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Wolfgang Grandegger <wg@...ndegger.com>,
	Andrew Lunn <andrew@...n.ch>
Subject: Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

Hi Marek,

On 03.11.2015 22:41, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 10:24:23 PM, Oliver Hartkopp wrote:

>> Comparing to typical ethernet frames with 1500 bytes the 16 bytes for CAN
>> frames or 72 bytes for CAN FD frames are already too small in relation to
>> the socket buffer overhead.
>>
>> If you want to improve the memory efficiency for arinc290 you should
>> probably consider to implement a character device based driver instead of
>> creating a new network protocol family.
>
> See discussion:
>
> http://comments.gmane.org/gmane.linux.kernel/1512019
>
> Which is why I picked the socket variant.
>

Oh. This provides a completely new perspective.

So far we just discussed about the 32 bit messages to be handled and filtered 
by the kernel.

This could have been done by

1. A chardev interface driver

2. A netdev interface driver (drivers/net/arinc429/...) and using PF_PACKET 
together with Berkley packet filtering (BPF)

3. A netdev interface driver (drivers/net/arinc429/...) and using PF_CAN which 
would lead to a arinc data structure which needs to be struct can_frame 
compatible.

But if you plan to implement the transport protocols (FTP/MAC) inside the 
Linux kernel that have been discussed in the URL above this would be a real 
difference to CAN related protocols. Only from that perspective a new protocol 
family would make sense.

(..)
>>  From what I've read so far there's also the sending of cyclic messages and
>> label filtering outside the HW - or why did you copy/paste the can_id/label
>> filter mechanism from af_can.c ?
>
> I think you might be mixing two people together here, I sent the patch and
> Andrey and Aleksander are working for some other interested company.

Sorry. Will try to bash only *you* in the future :-))

> The label filtering makes sense if you want to separate what you receive on
> which socket in userland, which allows an application to receive only relevant
> traffic.

ok.

>
> Hardware-accelerated filtering is another thing and at this point, we should
> not mix these two things. Does CAN framework have any such support for hardware
> assisted can_id filtering btw ?
>

No. We discussed about it. But the HW filter capabilities of CAN controllers 
have a wide range of functionality. Most filters make only sense in ECUs that 
pick specific CAN IDs for their functionality. It made no real sense to have 
an administrative configuration interface that limits the view to the CAN bus 
for the entire system. An we never had performance issues with the filtering 
in the softirq context in af_can.c

>>> I'd  prefer to have ARINC framework simple as it could be and separate
>>> from  CAN,  as  these  buses are not similar, besides desire to re-use
>>> SocketCAN interface/API to expose ARINC429 bus.
>>

>> Maybe you don't need that fancy stuff that comes with PF_CAN. Did you ever
>> thought about implementing a chardev driver for the ARINC429 hardware?
>> There are out-of-tree CAN drivers (e.g. can4linux or PEAK System Linux
>> driver) that handle the transfer of data structures (CAN frames) from/to
>> kernel space via character device. See an example at
>> https://en.wikipedia.org/wiki/Can4linux
>
> I guess I can answer that -- yes, I did, see above.
>

Ok - it seems to stick on the future plan whether it makes sense to implement 
the FTP/MAC transport protocols inside the kernel or not.

What's your thought about that?

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html