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