Joerg Schilling wrote:
> James Carlson <carls...@workingcode.com> wrote:
>
>> TIOCMIWAIT, though, sounds like an interesting addition.
>>
>> The best you can do for TIOCMIWAIT is to open the /dev/cua/ node in
>> blocking mode in order to wait for DCD assertion. There's no way to
>> wait for any of the other input signals (such as CTS or RI).
>
> It may sound interesting, but it is something that orevents reliable modem
> usage.
>
> /dev/cua/* and /dev/tty/* are implemented in Solaris in a way that either
> allows to open /dev/cua/* or /dev/tty/* depending on whether there is a
> carrier
> or not. If you do it in a different way, ingoing and outgoing programs may
> confuse each other.
I don't think the issue you're talking about is really related to the
original poster's question. It turns out that he has a small external
device that toggles the RI input in response to external events, and
he'd like to write an application to monitor these events. He's just
bit-bashing for a special application. It's got nothing to do with
dial-in or out.
As for the in/out scheme on Solaris, it may be confusing to application
developers, but there's really no such confusion in the drivers themselves.
There are two types of node available for each serial interface: a
"dial-out" node under /dev/cua/ and a "dial-in" node under /dev/term/.
(There's no such thing as "/dev/tty/" on Solaris or OpenSolaris; perhaps
you meant "/dev/tty*" instead, which are merely aliases for the
"/dev/term/" nodes.)
A "dial-in" node has the following behavior:
- It always blocks on open when DCD is deasserted. When blocked in
this way, future opens are still allowed.
- When DCD is asserted *and* no dial-out stream is currently open, the
open(2) call will complete, and the application then has access to
the serial port.
- When DCD goes away, the application still has access until it
closes the file descriptor (which it is expected to do).
A "dial-out" node does this:
- It blocks waiting for DCD only if the open is done in blocking
mode. A normal application will open once non-blocking, set that
descriptor to blocking I/O, use ioctls and read and write text as
necessary to set up the external device for a call ("ATDT"), and
then open a *second* file descriptor in blocking mode on the same
node in order to wait for DCD to go active.
- As long as at least one dial-out stream is open on the device,
all dial-in streams (if any) are kept sleeping.
- If you attempt to open a dial-out node while a dial-in stream is
already active, you get EBUSY. (There is, unfortunately, no good
way to wait for an active dial-in stream to release the device.)
Finally, all reasonably well-written dial-out serial programs use the
SysV /var/spool/locks/LK.DDD.MMM.NNN nodes to coordinate access, where
"DDD" is a three-digit decimal number representing the major() part of
st_dev for the device, "MMM" is the major() part of st_rdev, and "NNN"
is the minor() part of st_rdev.
In general, I'd say that if you don't know what you're doing, then you
probably want the /dev/cua/ node by default, and probably with
O_NONBLOCK set. The /dev/term/ nodes are intended for use by getty (or
the execrable SysV equivalent), and not by regular applications.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
