-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Welcome to the linux-usbtmc wiki!
- mutex_lock_interruptible(..) instead of mutex_lock(..)? Yes, since ...
- tips to detect memory leaks of flying urbs? See https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html#kernel-memory-leak-detector
- Detection of ZLP (Zero length packages) possible? Yes, an URB can return with a received size of 0 or just less than requested.
- suspend/resume: How do we deal with current IO traffic?
- TODO: assign POLLPRI to SRQ, and assign POLLIN|POLLRDNORM to normal read data!! Can we exchange the event flags and break existing applications? Yes, Dave would be ok with the new Definition.
- How shall we deal with subsequent asynchronous calls (usbtmc_generic_write/read)? Solved in usbtmc_generic_read.
- Which timeout error should be used ETIME or ETIMEDOUT?
- Much more drivers are using ETIMEDOUT
- Which timeout values are allowed 0..MAX_SCHEDULE_TIMEOUT (-1)
- Current minimum timeout of 500 ms is not recommended. Could be e.g. 10 ms.
- Do we need an IOCTL to programmatically read the version of the driver? Or do we just use a modinfo approach?
- gk: We can use an ioctl e.g. USBTMC_IOCTL_VERSION that just returns a (__u32)1. The value is incremented when the API changes (e.g. a new flag or a new ioctl).
- Note that newer kernel uses now EPOLLOUT, EPOLLIN, EPOLLPRI etc.
- testing pm-suspend. Done
- Useful timeouts. Important Check abort timeout and ReadSTB timeout!
- io_buffersize should be multiple of wPacketSize (or 1024). Done io_buffersize removed!
- default 0f io_buffersize? Removed
- Implement USBTMC_IOCTL_VERSION. Done
- Bug: Endless loop in device clear!
Q: It's not clear to me how the new read and write ioctls relate to the existing read() and write() functions. How do I (as an end user) choose? Under what set of circumstances should I be using one vs. the other? Will they interoperate (i.e. use read() for some reads, ioctl for others)?
A: The existing read() and write() function should still be used for current and future applications that wants a convenient way to communicate with T&M instruments. We do our best to keep the existing Linux USBTMC driver compatible with current applications. There is only one exception. The POLLIN flag is replaced with POLLPRI to signal a SRQ. The new ioctl functions are designed to meet the requirements for a VISA Library that wants to perform synchronous and asynchronous I/O. On top of the VISA layer there exists many IVI-Drivers or applications like LabView, Matlab, Keysight VEE, etc. which do not communicate directly with a USBTMC device. The new ioctl functions also allows vendor specific I/O and provides more options to test an USBTMC device. The current read()/write() functions does not have a good bandwidth (e.g. see test-raw.c). However we intend to improve them, too. Mixing the read()/write() functions with the new ioctl functions is not recommended, since the USBTMC_IOCTL_WRITE / READ functions fill out the USBTMC header in userland (VISA layer). Furthermore the new ioctl functions does not automatically call the abort or clear halt functions.