cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
daryllee
Explorer
Explorer
729 Views
Registered: ‎10-08-2016

ioctl() issue in dma-proxy.c

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.

0 Kudos
Reply
1 Reply
daryllee
Explorer
Explorer
705 Views
Registered: ‎10-08-2016

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.

0 Kudos
Reply