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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
