> >It doesnt however seem to guarantee they wont get hung up on instantly
> >before they can issue a tcsetattr() ?
>
> IIRC, the hangup is only generated on a DCD *drop*, not on DCD being
> already low.
Thats fine. If you are using a serial port which has a remote adapter that
is running on a high speed RS485 network where DCD is raised and lowered
as packets go past perhaps you'd care to tell me how to handle it without
/dev/cua devices - and portably.
Well, (1) don't clear CLOCAL in the first place. CLOCAL is initialized
to be on by default by the kernel at boot-up time --- and that wasn't an
accident. (2) tcsetattr is one of the few ioctl's which is allowed
after a hangup, so it will work anyway.
Yes, this is a potential security hole which a user who left a program
running might possibly exploit, but there's little that user could do
other than a denial of service attack, and there are plenty of ways of
doing that anyway. The reason for this exception was that there there's
trashy hardware out there will cause the carrier detect line to *very*
quickly flap up and down if it is left floating. So in order to not
screw over users who accidentally clear CLOCAL, the tty code allows
tcsetattr() on a hung-up connection.
It happens to help out in your situation where you have a device which
likes to cause DCD to flap around a lot --- although in your case, where
the device is directly connected, I have to ask why CLOCAL is getting
cleared in the first place.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu