OSR5 <sys/termio.h>
Frank da Cruz
OK, after much experimentation I have given up on the idea of OSR5
being able to toggle DTR. But something else is bothering me now.
At compile time, Kermit #includes <sys/termio.h>, where the Bxxxx
symbols are defined for the supported serial speeds. Kermit source
contains preprocessor statements to add the supported speeds to
Kermit's speed list so, for example, you can type "set speed ?" and
see a list of supported speeds.
In OSR5, the highest speed that Kermit picks up is 38400 bps. Yet
<sys/termio.h> includes symbols all the way up to B921600, and they
are defined at top level, not within any #ifdefs. Hmmm, says I, maybe
some interaction of header files is preventing these symbols from
being picked up. But:
cd /usr/include
grep B9600 *.h */*.h
only turns up one definition: the one in <sys/termio.h>. I even
wrote a stupid program to isolate what is going on:
#include <stdio.h>
#include <sys/termio.h>
main() {
#ifdef B0
printf("B0\n");
#endif
#ifdef B50
printf("B50\n");
#endif
(etc etc....)
#ifdef B921600
printf("B921600\n");
#endif
}
and the result was exactly the same: it stopped at 38400. But just before
I went totally nuts, I tried "cc -E speeds.c > file", and found all kinds
of references in the result to /udk/usr/include... By golly, it was using
a totally different copy of termio.h than the one I was asking for, and
sure enough, that copy does not contain definitions for the high speeds.
But why is it doing this?
$ cd /
$ ls -ldga usr
drwxrwxr-x 25 root auth 512 Dec 14 1999 usr
$ cd /usr
$ ls -ldga include
drwxr-xr-x 5 bin bin 512 Dec 14 1999 include
$
I don't see any symlinks. Is cc hardwired to make the switch? And if
so, why put useless copies of header files in the /usr/include tree full
of features that developers want to use and then secretly use hidden
shadow copies instead that are only bare fragments of the visible ones?
I tried #including the real /usr/include/sys/termio.h and bombed out
as follows:
"./termio.h", line 574: undefined symbol: LDNAMEMAX
"./termio.h", line 574: integral constant expression expected
"./termio.h", line 735: cannot find include file:<sys/winsize.h>
There must be something I'm not getting... Is my OSR5 installation
bollixed or something?
- Frank
Jean-Pierre Radley
Which cc are you actually using: /usr/bin/cc, or /udk/usr/ccs/bin/cc?
The former is the default OSR 5 compiler, and looks under /usr/include.
The latter is the compiler to make OSR5/UnixWare compatible binaries, and
that's the one which finds its header files under /udk/usr/include.
The "normal" compiler's header files define serial speeds above 38400;
the ones in the UDK do not.
--
JP
Robert Lipe
>In OSR5, the highest speed that Kermit picks up is 38400 bps. Yet
><sys/termio.h> includes symbols all the way up to B921600, and they
>are defined at top level, not within any #ifdefs. Hmmm, says I, maybe
>some interaction of header files is preventing these symbols from
>being picked up. But:
>
> cd /usr/include
> grep B9600 *.h */*.h
>
>only turns up one definition: the one in <sys/termio.h>. I even
[ ... ]
>I went totally nuts, I tried "cc -E speeds.c > file", and found all kinds
>of references in the result to /udk/usr/include... By golly, it was using
>a totally different copy of termio.h than the one I was asking for, and
Your cc isn't what you think it is.
There are two distinctly different flavors of compilation environments
(These should have been merged years ago, but that's a different rant.)
/bin/cc is the "native" compiler and it uses libs in /lib/blah and headers
in /usr/include/blah. There is another compiler, the UDK compiler, that
generates binaries that also work on UW2 and UW7 (I can't recall if OU8
is officially supported or not) that is basically the UW7 compiler rooted
in /udk so the pathnames for libraries, startups, and includes all have
"/udk" prepended. Check your $PATH and I suspect you'll see that what
you're calling 'cc' is /udk/usr/ccs/bin/...
You're not the first one to be, uuuuh, suprised by all this.
RJL
Bela Lubkin
Furthermore, the two different development systems come from two
different installation procedures. The native OSR5 devsys is installed
from the main OSR5 operating system CD (the label even says so, in
medium-small print). The UDK comes on its own separate CD with big huge
letters, to make sure you install the wrong devsys, which you've
apparently done.
Or maybe not.
If /bin/cc exists (and works), you have both devsys's installed and just
have your path arranged wrongly. If not, you need to go install the one
from the main CD.
Both can be installed at once; control which devsys is activated by
where /udk/usr/ccs/bin is on your path -- before /bin to use UDK, after
/bin (or nowhere) to use native DS.
Even though you're using the same underlying device drivers and system
calls, I wouldn't be surprised if your DTR/RTS problems went away with
the native DS (possibly in combination with one of the various
workarounds I suggested). For example, the UDK libraries are probably
doing all sorts of gnarly structure translations on the ioctls you're
using -- more system-specific stuff like RTS/CTS settings might be
getting lost.
>Bela<
J. L. Schilling
>
> Even though you're using the same underlying device drivers and system
> calls, I wouldn't be surprised if your DTR/RTS problems went away with
> the native DS (possibly in combination with one of the various
> workarounds I suggested). For example, the UDK libraries are probably
> doing all sorts of gnarly structure translations on the ioctls you're
> using -- more system-specific stuff like RTS/CTS settings might be
> getting lost.
I've had mixed experiences in using the UDK compiler to build serial I/O
code to run on OpenServer. The RXTX open source implementation of javax.comm
(the Java serial I/O API) can be built with the UDK and runs correctly on
OSR 5.0.6a. (This is good since OSR5 Java native method code *has* to be
built with the UDK.) However the minicom serial I/O utility didn't work
when built with the UDK; I had to build it natively with the OSR5 dev sys.
For kermit's purposes, I don't see any advantages in trying to use the UDK,
so I think the OSR5 dev sys is the way to go.
Jonathan Schilling
Frank da Cruz
Bela Lubkin <be...@caldera.com> wrote:
: Robert Lipe wrote:
: > Your cc isn't what you think it is.
: > ...
: > There are two distinctly different flavors of compilation environments...
: > ...
: > You're not the first one to be, uuuuh, suprised by all this.
:
: Furthermore, the two different development systems come from two
: different installation procedures. The native OSR5 devsys is installed
: from the main OSR5 operating system CD (the label even says so, in
: medium-small print). The UDK comes on its own separate CD with big huge
: letters, to make sure you install the wrong devsys, which you've
: apparently done.
Apparently! And yes, that's exactly how it happened.
: If /bin/cc exists (and works)...
:
No, there is no /bin/cc and there is no /usr/bin/cc. Is that to be expected
if I installed OSR5 and then installed the UDK? "find / -name cc -print"
turns up only:
/udk/usr/ccs/bin/cc
: ... you have both devsys's installed and just
: have your path arranged wrongly. If not, you need to go install the one
: from the main CD.
:
Gee, I hope I can find the install cd and license keys and figure out how
to get cc from it.
This is a revelation. I wish I had known about these dual universes years
ago. It probably explains much of the difficulty I've had with OSR5 all
these years. Live and learn...
Thanks, guys.
- Frank
J. L. Schilling
> This is a revelation. I wish I had known about these dual universes years
> ago. It probably explains much of the difficulty I've had with OSR5 all
> these years. Live and learn...
The dual universe has only existed since the release of UnixWare 7 and the
UDK in March 1998. Any difficulties you had before that have to be explained
by something else ;-)
Jonathan Schilling
Frank da Cruz
I <f...@watsun.cc.columbia.edu> wrote:
: (about the /bin/cc vs /udk/.../cc dichotomy)...
:
: This is a revelation. I wish I had known about these dual universes years
: ago. It probably explains much of the difficulty I've had with OSR5 all
: these years. Live and learn...
A volunteer at another site built the same C-Kermit version on OSR5.0.5
with /bin/cc rather than UDK. Running it locally on my own 5.0.5 system
with external modem, where I can hear the noises and see the lights, I
find that:
. The high serial speeds now show up in the "set speed ?" list.
. You can actually use them (e.g. 57600 bps).
. Modem signals are still inaccessible (TIOCMGET).
. Hanging up with DTR off/pause/on still doesn't work.
If anybody has OSR5.0.5 code that drops DTR and then turns it back on
that works (e.g. brings DTR back up after the pause and if RTS also went
down, it comes back up too), I'd sure like to see it.
Also, via remote access to 5.0.6a, I *think* I verified that hanging up by
toggling DTR works there, but I can't be certain since I couldn't monitor
the lights. However, TIOCMGET still seems problematic -- it reported that
all modem signals (DTR, DSR, RTS, CTS, RI) were off when connected to a
modem with a fully populated modem cable. Can anybody confirm or deny this?
I have no information or reports about unpatched 5.0.6.
- Frank
John DuBois
>that works (e.g. brings DTR back up after the pause and if RTS also went
>down, it comes back up too), I'd sure like to see it.
I think you'll just need to close the device, open it, & re-initialize it.
>However, TIOCMGET still seems problematic -- it reported that
>all modem signals (DTR, DSR, RTS, CTS, RI) were off when connected to a
>modem with a fully populated modem cable. Can anybody confirm or deny this?
Well, I can tell you than on a stock 5.0.6a system and using a standard (sio)
port, this code:
#define _SVID3
#include <sys/termio.h>
#include <stdio.h>
main()
{
int bits;
if (ioctl(0,TIOCMGET,&bits)) {
perror("TIOCMGET");
exit(1);
}
else {
printf("MGET %x CTS=%d DSR=%d RNG=%d CAR=%d\n", bits,
!!(bits & TIOCM_CTS), !!(bits & TIOCM_DSR), !!(bits & TIOCM_RNG),
!!(bits & TIOCM_CAR));
exit(0);
}
}
shows exactly what the lines are set to, for example:
# tiocmget < /dev/tty2a
MGET 120 CTS=1 DSR=1 RNG=0 CAR=0
John
--
John DuBois spc...@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/
Frank da Cruz
John DuBois <spc...@deeptht.armory.com> wrote:
: In article <9sc7ku$81i$1...@newsmaster.cc.columbia.edu>,
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >If anybody has OSR5.0.5 code that drops DTR and then turns it back on
: >that works (e.g. brings DTR back up after the pause and if RTS also went
: >down, it comes back up too), I'd sure like to see it.
:
: I think you'll just need to close the device, open it, & re-initialize it.
As noted in an earlier posting, when I tried that on my 505 system:
tcgetattr(ttyfd, &ttcur);
close(ttyfd);
(pause)
ttyfd = open(name,O_RDWR|O_NONBLOCK);
tcsetattr(ttyfd,TCSADRAIN,&ttcur);
DTR and RTS drop for the desired interval and they both come on again.
However, any write() to the reopened device gets error 11, "Resource
temporarily unavailable". Did I miss a step? Or is this a difference
between 5.0.6a and earlier OSR5s?
: >However, TIOCMGET still seems problematic -- it reported that
: >all modem signals (DTR, DSR, RTS, CTS, RI) were off when connected to a
: >modem with a fully populated modem cable. Can anybody confirm or deny this?
:
: Well, I can tell you than on a stock 5.0.6a system and using a standard (sio)
: port, this code:
:
: #define _SVID3
:
Aha, maybe that was the missing piece. Thanks.
- Frank
John DuBois
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
> ttyfd = open(name,O_RDWR|O_NONBLOCK);
> tcsetattr(ttyfd,TCSADRAIN,&ttcur);
>
>temporarily unavailable". Did I miss a step? Or is this a difference
>between 5.0.6a and earlier OSR5s?
You missed a step (the same one that a lot of app writers did); it's one that
didn't trip anyone up until tty behaviour was made POSIX-correct in 5.0.0.
POSIX requires that O_NONBLOCK make tty io non-blocking, which is rarely what
you want - O_NONBLOCK is almost always used just to allow opening of a
modem-control line without DCD being asserted. After opening the device, you
need to turn off non-blocking mode with something like:
tcsetattr CLOCAL, else the following will disable IO until DCD is
asserted.
if ((flags = fcntl (ttyfd, F_GETFL)) == -1)
error...
flags &= ~O_NONBLOCK;
if (fcntl (ttyfd, F_SETFL, flags) == -1)
error...
I don't know why you didn't encounter this in earlier 5.0, and you also should
not encounter it until you've written enough data to fill up the tty output
buffer (that's when non-blocking mode causes writes to start failing with errno
11). But in any case, my guess is that adding the above will resolve your
problem.
Frank da Cruz
John DuBois <spc...@deeptht.armory.com> wrote:
: In article <9se63k$kqo$1...@newsmaster.cc.columbia.edu>,
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: > ttyfd = open(name,O_RDWR|O_NONBLOCK);
: > tcsetattr(ttyfd,TCSADRAIN,&ttcur);
: >
: >... any write() to the reopened device gets error 11, "Resource
: >temporarily unavailable". Did I miss a step? Or is this a difference
: >between 5.0.6a and earlier OSR5s?
:
: You missed a step (the same one that a lot of app writers did); it's one that
: didn't trip anyone up until tty behaviour was made POSIX-correct in 5.0.0.
Let's hear it for political correctess.
I stumbled on this trick (setting CLOCAL) yesterday independently, and now SCO
5.0.5 Kermit can hang up a modem by momentarily dropping DTR without wedging
itself afterwards. I suppose it should have been obvious -- after all, if
you do hang up the modem successfully, you can't really expect carrier to be
on afterwards.
Thanks! Now on to the next thing (modem servers...)
- Frank
John DuBois
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>In article <3beb40ea$0$79556$8ee...@newsreader.tycho.net>,
>John DuBois <spc...@deeptht.armory.com> wrote:
>: In article <9se63k$kqo$1...@newsmaster.cc.columbia.edu>,
>: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>: > ttyfd = open(name,O_RDWR|O_NONBLOCK);
>: > tcsetattr(ttyfd,TCSADRAIN,&ttcur);
>: >
>: >... any write() to the reopened device gets error 11, "Resource
>: >temporarily unavailable". Did I miss a step? Or is this a difference
>: >between 5.0.6a and earlier OSR5s?
>:
>: You missed a step (the same one that a lot of app writers did); it's one that
>: didn't trip anyone up until tty behaviour was made POSIX-correct in 5.0.0.
>:
>Let's hear it for political correctess.
>
>I stumbled on this trick (setting CLOCAL) yesterday independently, and now SCO
>5.0.5 Kermit can hang up a modem by momentarily dropping DTR without wedging
>itself afterwards. I suppose it should have been obvious -- after all, if
>you do hang up the modem successfully, you can't really expect carrier to be
>on afterwards.
Not setting CLOCAL should give you errno 5, not 11. Make sure you turn off
non-blocking mode too; its effect may not be as immediately obvious, esp.
for interactive io.