12-22-2017 08:04 AM
I have been using dma-proxy.c for several months now and just recently discovered that I have a hardware anomaly that I can work around by changing the way I use the ioctl() function. (The hardware anomaly is a sometimes-missing completion interrupt on the send transfer; the data is sent, but the interrupt doesn't happen, and I don't have time to debug that problem.) I started a few months ago with the version at https://github.com/mstuehn/dma_proxy, and later extended its ioctl() function to include another "ioctl_num", as exemplified in https://www.tldp.org/LDP/lkmpg/2.4/html/x856.html. This one terminates any pending transfers, and indeed it seems to perform as expected. A few days ago, I added a third ioctl_num. This one had as its object to pass over the "wait_for_transfer()" function call at the end of the transfer() function, so as to not block on completion.
Now the odd thing is that calls to ioctl() with that ioctl_num never arrive at the ioctl() function itself. The values of ioctl_num that I send are 0, 1, and 2, and ioctl() registers its activation with a printk() that displays the value. The problem is that ioctl() reports 0 and 1, but never 2. It is as if the OS code that interprets the application's call to the ioctl() API function is checking the ioctl_num and only recognizing 0 and 2, and not acting on any other. But I can't find any documentation to support that notion. Any insights on this would be welcome. For the moment, I have worked around this issue by packaging my "skip the wait" request inside the data structure passed to the function in its third argument.
I'm not sure this is the correct forum for this; if there are any suggestions for where to go with the question, I'm open.
12-22-2017 01:33 PM
Well, if this were easy, anybody could do it. I found this document (http://www.cs.otago.ac.nz/cosc440/labs/lab06.pdf) that told me two things about ioctl() that I didn't know and don't know where to find the definitive specification on:
1. They don't block in and of themselves, now that we are beyond kernel 2.6.3.
2. The ioctl_num parameter isn't as arbitrary as I had assumed.
That's what I love about this job--the supply of stuff to learn grows faster than my aborption rate.