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