On Tuesday, November 03, 2015 at 04:06:05 PM, Aleksander Morgado wrote: > On Tue, Nov 3, 2015 at 12:36 PM, Marc Kleine-Budde <m...@pengutronix.de> > wrote: > > On 11/03/2015 11:36 AM, Aleksander Morgado wrote: > >> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut <ma...@denx.de> wrote: > >>>>> I was thinking about this and I mostly agree with you. Obviously, > >>>>> copying the code this way was dumb. On the other hand, ARINC and CAN > >>>>> are two different sort of busses, so I'd propose something slightly > >>>>> different here to avoid confusion and prevent the future extensions > >>>>> (or protocols) from adding unrelated cruft into the CAN stack. > >> > >> I'd keep them separate not because ARINC may add unrelated cruft into > >> the CAN stack, but because ARINC is much simpler than CAN already... > > > > 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)
So does CAN, I don't see a problem re-using the filtering infrastructure here. > , 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). Aren't the RX-only/TX-only channels rather a special case ? In that case, you can register a device per each such channel and be done with it, no ? > 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. Best regards, Marek Vasut -- 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
