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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Nov 2015 16:06:05 +0100
From:	Aleksander Morgado <aleksander@...ksander.es>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
Cc:	Marek Vasut <marex@...x.de>,
	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Wolfgang Grandegger <wg@...ndegger.com>,
	Andrew Lunn <andrew@...n.ch>
Subject: Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

On Tue, Nov 3, 2015 at 12:36 PM, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> On 11/03/2015 11:36 AM, Aleksander Morgado wrote:
>> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut <marex@...x.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), 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). 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.

-- 
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html