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]

Message-ID: <814845359.20151103232627@cogentembedded.com>
Date:	Tue, 3 Nov 2015 23:26:27 +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.

> So when thinking about using PF_CAN as ARINC429 base ...

> This is the CAN frame structure:

> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n264

>     struct can_frame {
>             canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
>             __u8    can_dlc; /* frame payload length in byte (0 .. 8) */
>             __u8    __pad;   /* padding */
>             __u8    __res0;  /* reserved / padding */
>             __u8    __res1;  /* reserved / padding */
>             __u8    data[8] __attribute__((aligned(8)));
>     };


> So what about defining an arinc429_frame like this:

>     struct a429_frame {
>             __u32   label;   /* ARINC 429 label */
>             __u8    length;  /* always set to 3 */
>             __u8    __pad;   /* padding */
>             __u8    __res0;  /* reserved / padding */
>             __u8    __res1;  /* reserved / padding */
>             __u8    data[8] __attribute__((aligned(8)));
>     };
What  would  be  the  benefit  besides  reusing  CAN tools to have
arinc429 frame structure four times larger that it needs to be?

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.

There   is   no   real   processing  needed for ARINC429 frames inside
framework. Almost all features  are  done  by  HW  itself  (label  filters,
label  priority matching,   label   bit  flipping,  rate  selection,  parity
and  sdi decoding) or by application.

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.

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