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

[Vostrikov Andrey <andrey.vostrikov@cogentembedded.com>]

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