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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 3 Nov 2015 16:19:43 +0100
From:	Marek Vasut <marex@...x.de>
To:	Aleksander Morgado <aleksander@...ksander.es>
Cc:	"Marc Kleine-Budde" <mkl@...gutronix.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 Tuesday, November 03, 2015 at 04:06:05 PM, Aleksander Morgado wrote:
> 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)

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