On Tue, Sep 22, 2020 at 10:33 AM <guido@xxxxxxxxxxxxxxxxxx> wrote: > > > Hi George, > > We discussed some solutions to solve the race you found. > > Since we want to avoid future requests and compatibility problems > regarding the SRQ and Status Byte, we will fix the current ioctl. > Furthermore we add two ioctls which return the original status > message and avoid assumptions about the USB488 subclass definition. > > We will have the 3 STB ioctls: > > 1) USBTMC488_IOCTL_READ_STB always reads the STB from the device and > if the associated file descriptor has the srq_asserted bit set it ors > in the RQS bit to the returned STB and clears the srq_asserted bit. > > Comment: This ioctl will return the latest status byte again, but will > not loose the RQS bit sent by intermediate SRQ messages. This ioctl > should be conform with 488.2 devices. > > 2) USBTMC_IOCTL_GET_STB always reads the STB from the device and returns > the STB unmodified to the application. The srq_asserted bit is not changed. > > 3) USBTMC_IOCTL_GET_SRQ_STB if the associated file descriptor has the > srq_asserted bit set it returns the STB originally sent in the device > SRQ message and clears the srq_asserted bit otherwise it returns error > code ENOMSG. > > Please let us know your feedback and comments. Sounds great (and sorry for the late reply). This should allow for a variety of reliable application and device implementations. I can't think of anything else to add. > > Regards, > > Guido > >
