Tosoni a écrit :
Sounds like an equivalent to WaitCommEvent in Windows NT. But there is a problem in Linux, which does not exist in Windows where the serial port is locked by the requesting process: in Linux you would have to associate your "recorded state" with the requesting process, because several processes may use your new ioctl at the same time.
Yes the recorded state COULD BE recorded by the same process that makes the call. This process can get the status by reading the OUTPUT icount.reserved[0] field each time the ioctl(uart_wait_new_status) returns. Several processes can wait for a change each wrt to its own "recorded state".
Or, you can say that it's a feature of your ioctl to handle only one process :-)
This restriction is not necessary I think.
Also, in Windows there is an extra feature, you can set a mask of which signal changes you want to monitor, you might want this feature as well
It exists in the code. Indeed, the INPUT field icount.reserved[0] contains the corresponding mask. If this mask is 0, then the behavior is not to wait forever but to return immediately, given back the current modem status in the OUTPUT icount.reserved[0] field. Regards, Dominique LW - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
