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 18:37:39 +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 05:47:54 PM, Aleksander Morgado wrote:
> On Tue, Nov 3, 2015 at 4:19 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.
> 
> Aren't CAN IDs more than 8-bit long?

11bit for CAN, but that's a minor detail.

> Also, ARINC429 labels are logically identifying the data type of the
> value being sent, not a given "node" as CAN IDs are (If I'm not
> mistaken, correct me if wrong). A single system (e.g. IRS) will send
> multiple different labels (e.g. 310 for Latitude, 311 for
> Longitude...) to different consumers (e.g. IFE will read all those).

In that case, filter those LABELs which you want to receive and decide
on their datatype in your application based on the LABEL. This works
just fine in my opinion.

On the other hand, you cansend those LABELs which you want to transmit
as well, again the logic for determining which LABEL to send is in your
application.

> The way a receiver identifies what system generated a given word (as
> the same label may have different meaning if sent by different
> systems) is usually by mapping in which RX port the word was received
> (or also through the special 377 label which may be used as equipment
> ID).

Well that's fine, isn't it ?

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