Hello.
In a project we work on, we are using custom hardware that provides direct
access to low-level Fibre Channel protocol layers. So software (running on
linux host) can send/receive FC2 sequences and even individual FC1 frames.
This is used to work with "non-so-mainstream" FC protocols (such as those
used in avionics) that commodity FC hardware can't deal with.
I'm now working on drivers for that.
I was going to implement /dev/fcraw device class with ioctl()s to send and
receive FC1/FC2, and provide in-kernel API for particular device drivers.
This is something I've already done for mil-std-1553 devices, and also for
other devices, and have experience with.
Question I'd like to ask is - isn't it better to use socket-based API -
create FC protocol family, support sockets to send and receive FC2
sequences or FC1 frames, etc etc
I currently have very limited experience with in-kernel network layer.
Is there any practical benefit in doing socket-based API instead of a
custom ioctl()-based API (e.g.: easier to implement or to use)?
Maybe someone did FC protocol family support before? I wasn't able to find,
but still?
I guess that FC1 frames (~2200 bytes max) can map well into skb's, but what
about FC2 sequences that are up to 16 megabytes in size? Is linux network
layer ready to handle "messages" of that size?
If creating custom interface, I could use in-memory receive buffer that is
DMAed to by hardware, and read-only mmapped into consumer process address
space. Thus avoiding on-cpu copy, which could be essential for high data
rates of FC. Is something similar implementable within socket API?
[we have device that does FC2 in hardware, and can DMA received FC2
sequences in chunks of 64 kilobytes, but for application software, having
entire sequence continuous in application's virtual address space is much
preferred]
Also, to handle high data rate, I am thinking of early filtering. Such as
driver could first analyse header of particular incoming frame or sequence
(using direct access to adapter memory via pci), and then decide if it's
content should be DMAed from adapter memory to host memory or not. Doesn't
this conflict with socket API?
Any other advice on topic?
Thanks.
Nikita
P.S.
Btw, anyone interested in /dev/mstd1553 or /dev/arinc429? We can share some
code... although particular API implemented is overengineered and
questionable, and driver support is done only for virtual devices and for
several adapters manufactured by local Russian companies not widely known.