Doing an ioctl(fd, FIONREAD, &count) on HP-UX 11.23 using a file descriptor opened to a RealPort device file linked to a Digi PortServer TS 4 returns 0 in count when characters really are available, while performing the same operation on a file descriptor opened to a TCP socket on the same physical serial port on the Digi works correctly, returning a positive value.
Performing a read() regardless of the value returned by FIONREAD works both ways.
Any idea what the problem could be?
Hi,
Our HPUX drivers do not support the FIONREAD ioctl directly.
This is because whenever our drivers get read data, we send it directly up to the HPUX tty Line Discipline as soon as possible.
The tty Line Discipline then owns the data, and gives it to the user as the user requires.
Because of this passing of ownership of the data, we have no direct knowledge of how much read data there actually
is “pending” in the tty Line Discipline.
This is why we don’t even attempt to suppor that ioctl call.
So whenever a user sends in an ioctl of FIONREAD, our driver will tell the tty Line Discipline that we did not handle it, and that the tty Line Discipline should handle it on our behalf instead.
In this case, if what you are seeing is true, it suggests a problem in HP’s tty Line Discipline.
BTW,
In place of your ioctl call, you could also select() on the file descriptor (fd) with a 0 timeout.
This would return whether there is any read data available right away, based on their VMIN/VTIME setting.
Thanks for the info.
The program first did a poll() to determine if data was available, and then did an ioctl(FIONREAD) to see how much, and then read that number of characters. I’ve changed the program to assume that at least one character is available and the program now works fine.
Thanks again.