QNX RTOS v4 Knowledge Base
QNX RTOS v4 Knowledge Base
| Title |
Dev and SIGHUP |
| Ref. No. |
QNX.000009248 |
| Category(ies) |
Development, Character I/O |
| Issue |
We have written a serial driver for an intelligent card and everything works except for the raising of the SIGHUP signal on processes by Dev.
The change of CD status is detected correctly, and the following code is executed as a result (verified by the printf()'s.)
x09if ((mdm_change & DELTA_CD) != 0 && (dev->mode & MODE_NOHUP) == 0)
x09{
x09x09if (chstatus & CD_ACT)
x09x09{
x09x09x09status |= (*tti) (RCV_CARRIER, dev->tty, tti_ds);
x09x09x09printf("CD up: status = dn", status);
x09x09}
x09x09else
x09x09{
x09x09x09status |= (*tti) (RCV_HNGUP, dev->tty, tti_ds);
x09x09x09printf("CD down: status = dn", status);
x09x09}
x09}
x09if (status)
x09Trigger(status);x09// Dev does not seem to raise SIGHUP
x09x09
When the CD status is "up", status = 0. When "down" it is 18, which, according to a sin proxy, is a proxy owned by Dev32 and therefore seems to be valid.
The stty utility indicates raw mode. The hupcl flag toggles appropriately. However, the state of dev->mode & MODE_NOHUP does NOT toggle - I believe that Dev controls this flag and not the driver. Regardless of this, why are the SIGHUP signals not being raised on a process that has the device open when the proxy is triggered? As far as we can tell, the device registration procedure we use (based on Dev.ser and the devdrvr.txt document) is OK - everything else works. We tend to think that there is in fact something wrong with the way we're setting things up which is peventing Dev from raising the signal on the correct processes, or perhaps at all.
|
| Solution |
POSIX functionality (which is what Dev provides) allows for procesing of "loss of carrier", but has nothing to do when carrier is raised. The driver interface permits a carrier sense indication to be indicated, but it is essentially a no-op in a POSIX conforming system.
POSIX has a "lot" to say about what to do when carrier is lost...
MODE_NOHUP is an initialization flag - read-only after init
HUPCL does not govern whether the signal is sent to the process. That is governed by CLOCAL. HUPCL only tells Dev to drop outbound DTR on close. It has nothing to do with (software) signals.
What about "O_NONBLOCK"? "The open() function waits until the device is ready or available before returning." With -CLOCAL and carrier down, the modem/port is not "available"...
This is tested for compliance by POSIX test suites from NIST and X/OPEN.
Have you looked at tcsetct()? |
|
