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]

Message-ID: <CAAP7ucKWT++AbPPA2kvm965JSjsgCm0OMf0-Vnjwe-ck+xjZZQ@mail.gmail.com>
Date:	Tue, 3 Nov 2015 17:10:24 +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

>> 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.

I'd actually love having this for a simulator setup I use where I
currently physically connect cables from a TX channel in one adapter
to a RX channel in another adapter. But I'm not sure there's a
specific real usecase for that apart from testing purposes.

> - 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.

I'd say that a TX error count could be enough here. I'm not sure if
having the echo would justify making the TX channels also
read-capable.

Remember that the actual hardware will have read-only or write-only
channels itself. Each of the real hardware channels exposed in
userspace as interfaces will therefore be read-only or write-only, and
the user will need to know that before using them. An application
wanting to read from channels will need to open and read from the RX
channels only, an application wanting to write to the channels will
need to open and write the TX channels only. The kernel should somehow
specify the type for each of the channels, not to confuse the users.
The virtual interface with both R/W caps doesn't really match what you
would expect in a real interface.

-- 
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