On Thu, Jun 20, 2013 at 10:52:53AM +0200, Arnd Bergmann wrote: > On Thursday 20 June 2013, Guenter Roeck wrote: > > On Wed, Jun 19, 2013 at 11:45:30PM +0200, Arnd Bergmann wrote: > > > On Wednesday 19 June 2013, Guenter Roeck wrote: > > > > > > Since this is a standard protocol, a driver that just supports a specific > > > chip (1a) would be the worst option IMHO. > > > > > It would not be optimal, but straightforward and easy to implement. > > The most important aspect would be the user interface: We should not > merge a driver that implements a character device (or something else) > in a way that would not be compatible with a general subsystem. I think > designing a generic interface is the hard part here, much more so than > implementing an abstraction layer. > > > > A character device and a network protocol both sound reasonable, but > > > it really depends on the use cases: > > > > > > * Does Linux act both as the sender and receiver, or do you want to > > > support just one of the cases (which?)? > > > > > Both, depending on the use case. Some of those are > > > > 1) ACARS - > > > > http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System > > Rx and tx > > > > 2) CIDS - Cabin Intercommunication Data System > > Rx and tx > > > > 3) IRS (Inertial Reference System) and FMS (Flight Management System) > > Rx only > > Ok, I see. > > > > * Would you expect to always just transfer a single 32-bit word, or > > > are there larger chunks of logically contigous data? What are typical > > > and maximum sizes for those? > > > > > The raw protocol is chunks of 32 bit (Logical Data Unit, or LDU), which > > the protocol refers to as 'physical layer'. Broadcast messages such as > > those from IRS and FMS use this format. > > > > There is also bit-oriented data. The two protocols I am aware of are "Bit- > > Oriented File Transfer Protocol", and "Bit-Oriented Media Access Control > > (MAC) Protocol", which is supposed to be IEEE 802 compliant. Packet size > > is 3 to 255 LDUs for FTP and 3 to 1023 LDUs for the MAC protocol. > > Both include a SOF and EOF marker, so the actual data size would be 1-253 > > or 1-1021 LDUs. Each LDU carries 20 bit, and partial words are possible > > in 4-bit increments, which means the data transfer size is 4 to 20,420 bit > > (2,552.5 bytes) for the MAC protocol, and 4 to 5,060 bit (632.5 bytes) > > for FTP. > > > > Bit-oriented data is commonly used for ACARS and CIDS, where bi-directional > > communication is used. > > > > Details are available in Specification ARINC-429P3-19-2009, sections 2.5 > > and 3.0. > > You should be able to find it on the web if you are interested. > > Ok, this sounds like it would make a network type interface more > practical, at least for the 802 specific parts. > > > > * Would you expect the kernel to filter for specific data on the > > > receiver side? > > > > > Each LDU has an 8-bit label. Applications listen for specific sets of > > labels. > > The chips have a configurable hardware filter; if there are not enough > > hardware > > filters, the kernel would have to do the filtering. Either case, the kernel > > has to select protocol receivers (sockets or open file descriptors) based > > on bind/registration information. For example, one aplication may register > > for label 1,3,5, and 7, and another for labels 1, 3, 12, and 14. So there > > can > > be overlaps. > > Ok > > > > * Would a user space receiver want to always see all data from one > > > sender, or only the latest word? > > > > > The receiver would want to receive all data for the labels it has registered > > for. > > > > Hope this helps. Note that, at least as first step, I only envision to > > handle > > 4-byte units and pass those to/from user-space. Implementing the two link > > layer > > protocols would probably make sense, especially with the socket interface, > > but that would be a second step. > > My vote would be for a new socket family for the low-level protocol, > with room for extension later to support the advanced features. > > This should be one of the simplest socket implementations possible, if > you just need to send and receive 32 bit words, and can bind to a > a set of labels for rx as you described above. > > The only possible concern I see with that interface is slightly higher > latency than what you would be able to get with a straight read/write > based character device. > Any further feedback on this ?
Key question: Would a new address family have a chance of being accepted ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/