On Sat, 27 May 2006, Paul Giblock wrote: > Wolfgang - > > > Aaah... the user should not be able to send the second command, if the > > first command is not finished. So you basicly have 2 choices: > > a) let the user write() function sleep (=blocking) until the first > > command is finished. > > This _would_ be ideal except I would need a way to signal the write > command to unblock. This is impossible because I would have to signal > from the send callback which is in_interrupt.
... > > So, for seek() commands, you will have only two seek commands > > a) the command which is executed > > b) the command which waits until a) is finished. > > Yes, this should work reasonably well with the queue technique. I > could easily implement a). But how do I let b) block until a) is > finished? There is no way to signal from in_interrupt. Sure there is. You can call wake_up(), wake_up_process(), or complete() from within an interrupt handler. I tend to agree with what Wolfgang said: your driver should be tailored to meet the special requirements of your device and application. You might even be able to get away with a userspace driver using libusb instead of a kernel driver. Alan Stern ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
