With some modification, I have finally made the skel driver work with my device. I think I have some initial theories about the root cause of the problems that I ran into with skel: 1) The condition if (!dev->processed_urb) is always false in the beginning and this induces a wait without any scope for completion, so it has to be removed. 2) A blocking read and blocking write cannot happen simultaneously. This is because in read, we go to sleep after locking a mutex 'iomutex'. Before writing, we try to lock the same mutex, so if we try to write() from one thread (or process) while waiting for read() to complete in another, we will have both threads blocked, waiting indefinitely for each other (the device won't respond until you send data to it). This can be fixed by unlocking the mutex before entering into the wait but then that mutex might be there for a reason and I might be doing the wrong thing. 3) If the buffer associated with your read urb is not big enough to accommodate the packet that arrives over USB, the transfer request will fail with error -75 in the completion callback. We could handle this by either propagating the error back to the user or by issuing transfer requests with big enough buffers and keeping the data buffered until the user asks for it. Then we could give as much data as he asks for and keep the rest buffered. But in the latter case, the user may issue a read() call expecting a transfer to happen, but he might not necessarily see one (in case there is data already buffered). Also the buffer size would be somewhat arbitrarily chosen which is not nice. Does anybody have anything to add or oppose on this or would you guys rather have me send a patch along with my changes? Regards, Felix. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
