On 11/03/2015 04:06 PM, Aleksander Morgado wrote: >> What about maintainability? Why take care of two almost identical >> subsystems? With making one stack "simpler" you increase, from my point >> of view, the costs of maintaining even more. If you fix problems in one >> stack you have to adopt the other, too. > > If they can share common code, that's fine, that probably can be > worked around if needed. My main issues are actually with all the > behavior that CAN supports and doesn't make much sense in ARINC, like > the complex ID filtering scheme for example (ARINC just requires 256 > bits for a minimum filter),
I think it should be possible to use a simple/different filter mechanism for ARINC packages. > or the duplex TX/RX setup for channels > (channels are either RX or TX, not both), or the local > echoing/loopback (which wouldn't make much sense for TX-only > channels). Local echo/loopback comes in two flavours: - Other socket receive local generate frames, too. This is interesting if you want to merge two ARINC node on single device. - Sending socket receives send frame, too. This is useful if you need the feedback that the frame has _really_ been send, not just pushed into the networking stack. > The minimum subset of features required by an ARINC driver > is actually very small. Trying to "fit" ARINC as a subset of CAN may > actually be harder than keeping it separate maintainability wise. > Maybe the issue here is that the original patch is too CAN-like while > it shouldn't be, don't know. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
