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, 4 Nov 2015 00:52:22 +0300
From:	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
CC:	Aleksander Morgado <aleksander@...ksander.es>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	Marek Vasut <marex@...x.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, Oliver.

> 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.
Ok,  if there is no big difference using 4-bytes structure or 16-bytes
structures, I do not have any objections.

> 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.
I  suppose  such  drivers  have  been  implemented before, but by some
reasons  socket  API is preferred now. I do not have any details regarding
this.

>> It just adds complexity to implement translation in device driver from
>> can-like  structures  to  native  4-bytes message. Similar translation
>> will be needed in application as well.

> That's BS. You put the data into a struct a429_frame at driver level and you
> read the data from struct a429_frame on application level.

> Where is the 'translation'?
Ok,  I overreacted a bit. Even in current proposal it is needed to move
bytes in HI-3593 driver as  well, as this chip accepts label as last byte,
instead  of  first  one  in SPI transfers. It was just a wish to use
same data without any actions when moving it between framework and HW.

> 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 ?
It  is  not  I  who  copied CAN code, and I do not think that CAN label filter
mechanism  fits ARINC, as it looks overcomplicated for small label space
in ARINC429

-- 
Best regards,
Andrey Vostrikov

--
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