Re: [OpenIndiana-discuss] stty source code
2012-09-04 7:05, Reginald Beardsley пишет: Where does one find the source for the stty in 151a? https://hg.openindiana.org/ really isn't very helpful in this regard. All I want is what's needed to recompile stty w/ -g and run it under dbx. I'll deal w/ the dependencies if and when I have to. Try the OpenGrok interface at http://src.illumos.org to the illumos-gate and illumos-userland projects. Namely: http://src.illumos.org/source/search?project=illumos-gateproject=illumos-userlandq=stty This has several pages of hits, I'd bet on /illumos-gate/usr/src/ucbcmd/stty/ /illumos-gate/usr/src/cmd/ttymon/ /illumos-gate/usr/src/lib/libc/common/sys/ for starters... //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
James Carlson wrote: Reginald Beardsley wrote: I don't want any inbound connections. But the documentation I read suggested that one had to setup ttymon on the port. Possibly for no reason other than, This is what I did when it finally worked. Where'd you read that? Even when it's active, ttymon just camps out on the /dev/term/ (dial-in only) nodes, meaning that it'll stay asleep while you do your work on /dev/cua/. And it's not active on any of the normal serial ports by default and I believe that no reasonable person should make it active. The main blocking item in removing it is making sure that the system console service still works right after removal. The console uses ttymon -g anyway (i.e. ttymon pretending to be getty, and ignoring all the SAC/SAF stuff). On rare occations I setup another login port, I use ttymon -g on that too. -- Andrew ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On 09/06/12 20:37, Reginald Beardsley wrote: The real issue is the pathologically complex handling of serial lines in Solaris and the ambiguous documentation. I am not convinced that anyone, myself included, knows which direction is which. I know which direction is in and out for communication w/ the local host, but that is all I'm sure of. Coupled w/ the fact that no one seems to have done much w/ a serial port connection in many years makes it more difficult. I disagree. I've had some trouble with the USB drivers, to be sure, but not with serial I/O in Solaris. The driver naming scheme is fairly simple. /dev/term/* are for inbound connections, and their behavior is: - if DCD is not asserted, then open() blocks, and the tty is not busy. - when DCD is asserted and no other process has the /dev/cua node open, open() will unblock and the process has use of the line. - if another process opens the /dev/cua/ node, then the open() stays blocked (regardless of DCD) until the last close on /dev/cua/ occurs. The /dev/cua/* nodes are for outbound connections: - if some process has /dev/term/ opened with DCD asserted, then you get EBUSY. - otherwise, open() connects to the serial port right away and will either block (if DCD is down and it's a blocking open), or will complete (if DCD is up or if it's a non- blocking open). - if the open is blocked waiting for DCD to come up, it will wake up when DCD is asserted. Normal dial-out behavior is to do one non-blocking open of the /dev/cua/* node, communicate with the modem (or TA or whatever is out there), then open a second file descriptor on the same device in blocking mode, which will sleep until DCD goes high. As for the terminal modes, they're all explained in the termio(7I) man page in excruciating detail. However, they're frankly mostly obsolete, except for SUS and POSIX conformance, and except for controlling the low-level port configuration (bit rate, parity, hardware flow control, and so on). Normal applications that use serial ports immediately disable opost and icanon and do their own processing on the raw bytes because, frankly, who wants to have the driver corrupting the data? If you believe that there's ambiguity in the documentation, then I think it'd be a service to all users to point out the ambiguous points and (if at all possible) suggest non-ambiguous replacements. I last used tip 14 years ago to connect to my ISDN router. It took only a couple of minutes to setup. The first forth MCU also took a couple of minutes to setup. The second beat me senseless for 6 hours. In light of the long history of misery and suffering by system admins at the hands of serial port connections, this should not be a big surprise. When I actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached. That was a long time ago when Sun was a young upstart I'd not even heard of. I *may* build up OI from source so I can run under the debugger and resolve the issue. But because I've modified the remote host to emit NL-CR, it's really not important to me other than it would be nice to have a reasonably behaved facility for connecting over a serial line to a remote host. If I really get in a jam, I can run Linux. I just prefer not to if I can avoid it. If I elect to work on the OI/Illumos serial port discipline, it will be for aesthetic rather than practical reasons. I argue that the problems occurred because you did not understand how the components actually worked, and thus spent untold hours manipulating the wrong bits. I suggest getting a copy of C-Kermit rather than using tip. tip doesn't really do much in terms of terminal emulation -- it's truly ancient and assumes that you have equivalent UNIX systems at both ends -- while Kermit is highly configurable and has no such assumptions. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
The pathological complexity is in the morass of sac/saf stuff. It was much simpler in 4.1.1. And is simpler on other *nix. C-Kermit installed from source was my immediate response to the problem but I found it didn't seem to have the ability to do anything either which *really* surprised me. Perhaps you can direct me to kermit documentation that tells how to convert NL from the remote host to NL-CR on the terminal. I spent a great deal of time reading the docs and experimenting w/o finding way. If I continue down this rabbit hole, I'm going to run a loop from a real serial port to a USB adapter port w/ terminals at both ends. However, that requires configuring OI on another system. And I don't have a system w/ 2 serial ports so it's just a cobble anyway. As the required effort grows, the motivation is shrinking. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On 07/09/2012 14:47, Reginald Beardsley wrote: Perhaps you can direct me to kermit documentation that tells how to convert NL from the remote host to NL-CR on the terminal. I presume that NL is meant to be LF, this may helps you: http://fixunix.com/protocols/61525-convert-lf-lf-cr.html A really old post, but Kermit does not change that often nowadays. -- Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On 09/07/12 08:47, Reginald Beardsley wrote: The pathological complexity is in the morass of sac/saf stuff. It was much simpler in 4.1.1. And is simpler on other *nix. SAC/SAF is horrible, awful stuff from New Jersey. The less said about that, the better. If you have any dial-in service at all (really? in 2012?), you're much better off using mgetty instead. I had plans to remove that crap when I was at Sun, but I never got around to it -- other priorities and eventually a new opportunity intervened. If you have to touch pmadm and the rest of that stuff, then my condolences. Fortunately, it's got nothing to do with 'tip' or communicating with external devices, and is only tangentially related to serial ports. It's used for dial-in and locally-connected character cell terminals only. C-Kermit installed from source was my immediate response to the problem but I found it didn't seem to have the ability to do anything either which *really* surprised me. Perhaps you can direct me to kermit documentation that tells how to convert NL from the remote host to NL-CR on the terminal. I spent a great deal of time reading the docs and experimenting w/o finding way. set terminal lf-display crlf ... at least it's there on a modern C-Kermit. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Thanks. I've not looked at the source yet, but it doesn't appear to be in the last (9.x) release. However, that might just be a documentation glitch. It clearly wasn't in 8.x which I find really surprising. --- On Fri, 9/7/12, Udo Grabowski (IMK) udo.grabow...@kit.edu wrote: From: Udo Grabowski (IMK) udo.grabow...@kit.edu Subject: Re: [OpenIndiana-discuss] stty source code To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org Date: Friday, September 7, 2012, 8:00 AM On 07/09/2012 14:47, Reginald Beardsley wrote: Perhaps you can direct me to kermit documentation that tells how to convert NL from the remote host to NL-CR on the terminal. I presume that NL is meant to be LF, this may helps you: http://fixunix.com/protocols/61525-convert-lf-lf-cr.html A really old post, but Kermit does not change that often nowadays. -- Dr.Udo Grabowski Inst.f.Meteorology a.Climate Research IMK-ASF-SAT www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technology http://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 -Inline Attachment Follows- ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On 07/09/2012 16:03, Reginald Beardsley wrote: Thanks. I've not looked at the source yet, but it doesn't appear to be in the last (9.x) release. James Carlson is right, 'set terminal lf-display crlf' is available in the 9.0.302 release (Unix), no need to fiddle with source code. -- Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
I don't want any inbound connections. But the documentation I read suggested that one had to setup ttymon on the port. Possibly for no reason other than, This is what I did when it finally worked. In principle serial line comms are simple, but in practice the exceptional cases can eat you alive. --- On Fri, 9/7/12, James Carlson carls...@workingcode.com wrote: From: James Carlson carls...@workingcode.com Subject: Re: [OpenIndiana-discuss] stty source code To: openindiana-discuss@openindiana.org Date: Friday, September 7, 2012, 8:39 AM On 09/07/12 08:47, Reginald Beardsley wrote: The pathological complexity is in the morass of sac/saf stuff. It was much simpler in 4.1.1. And is simpler on other *nix. SAC/SAF is horrible, awful stuff from New Jersey. The less said about that, the better. If you have any dial-in service at all (really? in 2012?), you're much better off using mgetty instead. I had plans to remove that crap when I was at Sun, but I never got around to it -- other priorities and eventually a new opportunity intervened. If you have to touch pmadm and the rest of that stuff, then my condolences. Fortunately, it's got nothing to do with 'tip' or communicating with external devices, and is only tangentially related to serial ports. It's used for dial-in and locally-connected character cell terminals only. C-Kermit installed from source was my immediate response to the problem but I found it didn't seem to have the ability to do anything either which *really* surprised me. Perhaps you can direct me to kermit documentation that tells how to convert NL from the remote host to NL-CR on the terminal. I spent a great deal of time reading the docs and experimenting w/o finding way. set terminal lf-display crlf ... at least it's there on a modern C-Kermit. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Reginald Beardsley wrote: I don't want any inbound connections. But the documentation I read suggested that one had to setup ttymon on the port. Possibly for no reason other than, This is what I did when it finally worked. Where'd you read that? Even when it's active, ttymon just camps out on the /dev/term/ (dial-in only) nodes, meaning that it'll stay asleep while you do your work on /dev/cua/. And it's not active on any of the normal serial ports by default and I believe that no reasonable person should make it active. The main blocking item in removing it is making sure that the system console service still works right after removal. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Andrew,
There are no serial ports and hence no /dev/term/b on this system. In fact if
the USB-RS-232 adapter is not plugged in, there is no /dev/term or /dev/cua
either. Which may explain some of the weirdness when I was setting up the port
as I don't think I had plugged in the Keyspan adapter when I started
configuring it. /dev/{term,cua}/0 don't get created until you plug in the
adapter and disappear when you unplug it.
ttymon holds /dev/term/0, so even root or uucp cannot open /dev/term/0. stty
just hangs until interrupted. Everything I've read suggests that it is not
possible to have a port be outbound only and that is must be bidirectional.
However, I've not attempted to test that. I've got enough annoyance as it is.
However, I can see lots of opportunity for trouble w/ ttymon running on a port
that goes away when the USB-serial adapter is unplugged.
I can open /dev/cua/0 w/ stty, but do not seem to be able to make any changes.
To wit:
root@openindiana:~# /bin/sh
root@openindiana:~# su uucp
root@openindiana:~# stty -a /dev/term/0
^Csu: /dev/term/0: cannot open [Interrupted system call]
root@openindiana:~# stty -a /dev/cua/0
speed 9600 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
root@openindiana:~# stty olcuc /dev/cua/0
root@openindiana:~# stty -a /dev/cua/0
speed 9600 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echokeroot@openindiana:~# stty olcuc
/dev/cua/0; stty -a /dev/cua/0
speed 9600 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
Note that attempting to set olcuc on /dev/cua/0 had no apparent effect.
Reg
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
The stty changes will be lost when the last stream closes and the port
settings are reset, which is probably the very instant that the stty
command which makes the changes exits in your example. So this will only
work if something else is holding the port open. That's why I said try
it when tip is running.
Alternatively, just to check you can change the parameter, use some
other command in another window to keep it open, such as
sleep 1 /dev/cua/0
Reginald Beardsley wrote:
Andrew,
There are no serial ports and hence no /dev/term/b on this system. In fact if the
USB-RS-232 adapter is not plugged in, there is no /dev/term or /dev/cua
either. Which may explain some of the weirdness when I was setting up the port as I
don't think I had plugged in the Keyspan adapter when I started configuring it.
/dev/{term,cua}/0 don't get created until you plug in the adapter and disappear when
you unplug it.
ttymon holds /dev/term/0, so even root or uucp cannot open /dev/term/0. stty
just hangs until interrupted. Everything I've read suggests that it is not
possible to have a port be outbound only and that is must be bidirectional.
However, I've not attempted to test that. I've got enough annoyance as it is.
However, I can see lots of opportunity for trouble w/ ttymon running on a port
that goes away when the USB-serial adapter is unplugged.
I can open /dev/cua/0 w/ stty, but do not seem to be able to make any changes.
--
Andrew
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Reginald Beardsley wrote: Sorry, I missed that detail. I just opened the connection w/ tip, went to the window where I was setuid to uucp and did stty olcuc /dev/cua/0 then back to the tip window. No effect. Everything is still lower case. Don't forget opost. And don't forget that the output options you're changing on /dev/cua/0 will reflect how that port processes output text going *TO* that serial port, and not the data you see coming back. If your concern is (as it was before) with the characters coming from that remote system and being displayed on your xterm, then here are the players involved: - remote system transmits some characters - the /dev/cua/0 tty receives them and processes according to the current input settings on that device - tip reads some data from the tty and writes it to stdout - tip's stdout is the slave side of the pty connected to xterm (this is your session tty) - the pty's output is processed by the output settings on that pty - xterm reads the master side of the pty and decides (based on configuration) how to render those characters for the display - xterm writes the characters to the display As you can see, doing stty on /dev/cua/0 may or may not do what you desire to do here. More likely, I'd expect that cranking up tip and then doing stty on the pty that tip is using will produce the sorts of results you want. But it's still the Wrong Way To Solve The Problem because it's based on a fairly fundamental set of misunderstandings. By far, I believe the best way to solve the problems you're having here are to either (a) use something with more sophisticated terminal emulation processing than just 'tip', which inherently assumes that you've configured the remote terminal configuration to be compatible with the local terminal emulator (which you have not done), or (b) reconfigure xterm and/or the remote system such that they have compatible terminal emulation modes. At this point, I think I need to make a non-setuid copy of tip and run tip under truss from a shell which is setuid to uucp. I'll have to wait until tomorrow to try that though as other things will take up the rest of the day. If you run truss as user 'uucp' or as 'root', you shouldn't have that problem. Simple enough to try if all you're doing is debugging. No need to make a copy. I'm beginning to suspect that there's something in the USB serial driver which is being more helpful than it should. So another thing is to spin up OI on a box w/ a real serial port and see how it behaves. I still think you're really barking up the wrong tree here, and it makes the problem far harder to solve. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On Thu, Sep 06, 2012 at 11:45:45AM -0400, James Carlson wrote: By far, I believe the best way to solve the problems you're having here are to either (a) use something with more sophisticated terminal emulation processing than just 'tip', which inherently assumes that you've configured the remote terminal configuration to be compatible with the local terminal emulator (which you have not done), or (b) reconfigure xterm and/or the remote system such that they have compatible terminal emulation modes. Keep in mind that the function of `tip' is to emulate an ASCII terminal. To do that, it places the terminal in raw mode, disabling most of the tty settings. When you type a line of text followed by [Enter], it sends the text followed by CR (0x0d). The device at the other end of the serial line should echo each of those characters, including the CR. If that device is another Unix system, its tty will be in cooked mode. That means that it will send a LF (0x0a) after the CR. The cursor on your terminal should first return to the left, and then drop down one line. A firmware device should be doing the same thing. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
never use USB- Serial when you're testing something. There is a huge
difference between products, and the bad products behave very unpredictable.
Don't forget that the voltage of USB is 5V MAXIMUM but can be much lower
depending on the hardware, legacy serialports need a good 5V for a logical
1.
So communication can be disrupted by voltagedrops because the logical 1's
are not transmitted at the right voltage.
-Original Message-
From: Reginald Beardsley [mailto:pulask...@yahoo.com]
Sent: donderdag 6 september 2012 17:14
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] stty source code
Sorry, I missed that detail. I just opened the connection w/ tip, went to
the window where I was setuid to uucp and did stty olcuc /dev/cua/0 then
back to the tip window. No effect. Everything is still lower case.
At this point, I think I need to make a non-setuid copy of tip and run tip
under truss from a shell which is setuid to uucp. I'll have to wait until
tomorrow to try that though as other things will take up the rest of the
day.
I'm beginning to suspect that there's something in the USB serial driver
which is being more helpful than it should. So another thing is to spin
up OI on a box w/ a real serial port and see how it behaves.
--- On Thu, 9/6/12, Andrew Gabriel illu...@cucumber.demon.co.uk wrote:
From: Andrew Gabriel illu...@cucumber.demon.co.uk
Subject: Re: [OpenIndiana-discuss] stty source code
To: Discussion list for OpenIndiana
openindiana-discuss@openindiana.org
Date: Thursday, September 6, 2012, 9:34 AM The stty changes will be
lost when the last stream closes and the port settings are reset,
which is probably the very instant that the stty command which makes
the changes exits in your example. So this will only work if something
else is holding the port open. That's why I said try it when tip is
running.
Alternatively, just to check you can change the parameter, use some
other command in another window to keep it open, such as sleep 1
/dev/cua/0
Reginald Beardsley wrote:
Andrew,
There are no serial ports and hence no /dev/term/b on
this system. In fact if the USB-RS-232 adapter is not plugged in,
there is no /dev/term or /dev/cua either.
Which may explain some of the weirdness when I was setting up the port
as I don't think I had plugged in the Keyspan adapter when I started
configuring it. /dev/{term,cua}/0 don't get created until you plug in
the adapter and disappear when you unplug it.
ttymon holds /dev/term/0, so even root or uucp cannot
open /dev/term/0. stty just hangs until interrupted. Everything I've
read suggests that it is not possible to have a port be outbound only
and that is must be bidirectional. However, I've not attempted to
test that. I've got enough annoyance as it is.
However, I can see lots of opportunity for trouble w/ ttymon running
on a port that goes away when the USB-serial adapter is unplugged.
I can open /dev/cua/0 w/ stty, but do not seem to be
able to make any changes.
-- Andrew
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
The MCU is 3.3V, so it requires a level shifter to match the 5V coming from the USB-serial adapter to the MCU. The level shifter and Keyspan work just fine, though the USB driver may not be playing nice. The real issue is the pathologically complex handling of serial lines in Solaris and the ambiguous documentation. I am not convinced that anyone, myself included, knows which direction is which. I know which direction is in and out for communication w/ the local host, but that is all I'm sure of. Coupled w/ the fact that no one seems to have done much w/ a serial port connection in many years makes it more difficult. I last used tip 14 years ago to connect to my ISDN router. It took only a couple of minutes to setup. The first forth MCU also took a couple of minutes to setup. The second beat me senseless for 6 hours. In light of the long history of misery and suffering by system admins at the hands of serial port connections, this should not be a big surprise. When I actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached. That was a long time ago when Sun was a young upstart I'd not even heard of. I *may* build up OI from source so I can run under the debugger and resolve the issue. But because I've modified the remote host to emit NL-CR, it's really not important to me other than it would be nice to have a reasonably behaved facility for connecting over a serial line to a remote host. If I really get in a jam, I can run Linux. I just prefer not to if I can avoid it. If I elect to work on the OI/Illumos serial port discipline, it will be for aesthetic rather than practical reasons. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Thanks. --- On Wed, 9/5/12, Yuri Pankov yuri.pan...@gmail.com wrote: From: Yuri Pankov yuri.pan...@gmail.com Subject: Re: [OpenIndiana-discuss] stty source code To: openindiana-discuss openindiana-discuss@openindiana.org Date: Wednesday, September 5, 2012, 7:57 AM On Tue, 4 Sep 2012 14:40:29 -0700 (PDT), Reginald Beardsley wrote: I've cloned the repository but find that the Makefile is expecting state to be set in the shell. Where would I find details on what I need to have set to compile just the things in usr/src/cmd/ttymon Is that possible? I'm really not eager to take on building everything as my OI box is a dual core Atom. http://wiki.illumos.org/display/illumos/How+To+Build+illumos ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
I find that I am unable to convert a newline returned by a remote host to NL-CR for display in a terminal window. So instead of: ok ok ok I get: ok ok ok I thought I'd try to find out why. I also found I can't actually set -onlcr w/ stty though I can toggle olcuc. Some things in stty work and some don't. I've actually modified the forth interpreter to send NL-CR and reassembled the code, so my original problem is solved. But it bugs me that things don't seem to work properly. While ttys are not used much now in the wider world, they are still heavily used as the interface to microcontrollers both for interaction and for loading new firmware. I'm *very* resistant to having to use Linux for this and simply won't use Windows which is the predominate environment for working w/ microcontrollers. Unfortunately there's a fair bit of open source stuff that doesn't like Solaris :-( It was a good bit of work to get this far. In view of the admin overhead, I'll probably defer working on ttymon friends until I can setup a faster OI machine. Working on OI wasn't actually in my plans at this time. Thanks for the pointers. Have Fun! Reg --- On Wed, 9/5/12, James Carlson carls...@workingcode.com wrote: From: James Carlson carls...@workingcode.com Subject: Re: [OpenIndiana-discuss] stty source code To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org Date: Wednesday, September 5, 2012, 7:52 AM Reginald Beardsley wrote: I've cloned the repository but find that the Makefile is expecting state to be set in the shell. Where would I find details on what I need to have set to compile just the things in usr/src/cmd/ttymon Is that possible? Look for the bldenv and ws scripts, part of the ON build tools in usr/src/tools. A good starting point might be: http://hub.opensolaris.org/bin/view/Community+Group+on/devref_4 I'm really not eager to take on building everything as my OI box is a dual core Atom. Building just a portion of the tree can be a little tricky. In general, you have to do a make install in usr/src/head to make sure that you have a proto area with the right header files. You might then be able to build in usr/src/cmd/ttymon, but it's very likely that you'll have to build some of the libraries on which it depends first. The ON build was never designed to allow builds of individual parts of the tree, except after building everything. An interesting (and possibly useful) project would be to break up the usr/src/cmd and usr/src/lib trees into separate projects, so that each can be built separately. Doing so, though, likely requires a lot of careful planning so that flag-day changes are still reasonably doable. If you have a really slow target machine, it might be an interesting idea to work on a cross-compilation environment on a faster one. I'm not sure, though, how hard that'd be. Why are you hacking at stty ... ? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Reginald Beardsley wrote: I find that I am unable to convert a newline returned by a remote host to NL-CR for display in a terminal window. So instead of: ok ok ok I get: ok ok ok It's unclear to me what problem you're trying to solve. A terminal window contains a terminal emulator that's displaying data from a remote system. The remote system decides what it will send, and that's what stty affects. Stty doesn't (normally, at least) affect what the terminal window itself does with the data it sees. The reason I say that is that the ok prompt you're showing looks like it comes from a SPARC OBP prompt. If it does, then what I think you'd need is either an OBP command to change the CF/LF behavior or a different terminal emulator or configuration. OBP isn't UNIX and doesn't have stty. I thought I'd try to find out why. I also found I can't actually set -onlcr w/ stty though I can toggle olcuc. Some things in stty work and some don't. I sometimes find stty -g helpful in figuring out what the line is really configured to do, but I'm a little geeky that way. What does your stty -a output say? Does it say opost or -opost? If it's the latter, then there'll be no output processing at all. What application is using the tty in question, and does it issue any ioctls? If so, then all bets with stty may well be off -- applications can (and very often do!) change anything they want. The setting you logically want here is opost onlcr -onlret. I don't think it's related to your problem, though. I've actually modified the forth interpreter to send NL-CR and reassembled the code, so my original problem is solved. But it bugs me that things don't seem to work properly. While ttys are not used much now in the wider world, they are still heavily used as the interface to microcontrollers both for interaction and for loading new firmware. I'm *very* resistant to having to use Linux for this and simply won't use Windows which is the predominate environment for working w/ microcontrollers. Unfortunately there's a fair bit of open source stuff that doesn't like Solaris :-( It was a good bit of work to get this far. In view of the admin overhead, I'll probably defer working on ttymon friends until I can setup a faster OI machine. Working on OI wasn't actually in my plans at this time. I think you may well be barking up the wrong tree. Details on precisely what software you're using and what you have connected to what via a serial link would probably be helpful in getting a more useful response. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
This is an example of one symptom:
oi%rhb {9} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
oi%rhb {10} stty -onlcr
oi%rhb {11} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
Notice that stty did *not* toggle onlcr. As noted earlier, I can toggle olcuc
and some other output modes, but there are several I can't.
I started checking just the xterm window stty settings when I couldn't get tip
to do this by setting things in /etc/ttydefs. It appears to me that something
is broken in code which is common to stty and ttymon.
I'm using tip running in an xterm to connect to an USB-RS-232 adapter
connected to an MSP430G2553 installed in a TI MSP430 LaunchPad. The 'G2553 is
running a forth interpreter.
The example I gave looks like OBP because OBP is also a forth interpreter. I
should probably have commented on that previously. It's not really relevant,
but could be confusing.
I have two different forth interpreters that run on the MSP430G2553, a 20 pin
DIP w/ 16K flash 512 byte RAM. One was sending NL-CR and worked properly.
The second sent just NL which ttymon tip *should* be able to convert to NL-CR
for the display terminal, but did not.
As noted previously, I've now modified the second forth so that it sends NL-CR
and things work fine for my purposes.
In summary, I'm connecting to a remote host over a serial line. Old and
obsolete cruft to most these days, but the predominate means of communicating
w/ microcontrollers today and probably always will be. It only takes 2 pins,
Rx Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU pins
are very precious. It also doesn't even require a UART in the MCU, though many
have them. So *any* MCU w/ 2 free pins can use RS-232 to talk to the outside
world.
This is what stty ttymon exist for. But it doesn't seem to work and appears
to have been broken for some time as Solaris 10 has the same problem. Nemeth
et al note Solaris serial line discipline is a mess. However, it appears to be
worse than that. It appears to be broken.
Have Fun!
Reg
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Reginald Beardsley wrote:
This is an example of one symptom:
oi%rhb {9} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
oi%rhb {10} stty -onlcr
oi%rhb {11} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
You're probably best off just using truss -vioctl to figure out what
those commands are actually doing. I'll bet that you see a TCGETS with
oflag set to 005 followed by a TCSETSW with oflag set to 001,
showing that stty is in fact attempting to toggle that bit.
Then, when you do stty -a again, oflag is stubbornly set to 005.
The conclusion you can draw from that is that there's nothing at all
wrong with stty -- it's doing precisely what you asked -- and that it's
something else that's being cantankerous.
As an experiment, try this:
stty -onlcr ; stty -a
You may well find that the output is jagged (due to the lack of
onlcr), and that the output includes -onlcr.
The conclusion to draw from that experiment is that you're being
confused by your shell. The shell itself (on issuing the prompt) is
helpfully setting some sane stty modes for you.
In other words, recompiling stty isn't going to do anything useful.
I'm using tip running in an xterm to connect to an USB-RS-232 adapter
connected to an MSP430G2553 installed in a TI MSP430 LaunchPad. The 'G2553
is running a forth interpreter.
OK. I expect that the problems you have are related to the behavior of
tip, not of stty.
The example I gave looks like OBP because OBP is also a forth interpreter. I
should probably have commented on that previously. It's not really relevant,
but could be confusing.
It's relevant because that remote system is sending data that is then
copied by tip through the tty to xterm. Knowing what's going on
necessarily involves knowing precisely what the remote system is
expected to send.
I have two different forth interpreters that run on the MSP430G2553, a 20 pin
DIP w/ 16K flash 512 byte RAM. One was sending NL-CR and worked properly.
The second sent just NL which ttymon tip *should* be able to convert to
NL-CR for the display terminal, but did not.
When you're running tip in the foreground, it's in charge of the modes
on the tty. stty has very little to do with it.
Looking at the tip source code (usr/src/cmd/tip/), it looks like tip
always puts the tty into raw mode (c_oflag = 0, and c_flag ~ICANON)
when handling data from the remote system.
Thus, that bare NL is going straight to xterm, and it's doing what the
xterm's default VT102-like terminal emulation tells it to do. If this
is really xterm (and not the GNOME Terminal application or something
else), then setting autolinefeed (accessed by holding the ctrl key and
pressing the middle mouse- button) should fix the problem.
In short, the configuration of the terminal emulator (xterm in this
case) MUST match what the remote system thinks it's talking to. If it
doesn't, you'll see unfortunate results.
As noted previously, I've now modified the second forth so that it sends
NL-CR and things work fine for my purposes.
In summary, I'm connecting to a remote host over a serial line. Old and
obsolete cruft to most these days, but the predominate means of communicating
w/ microcontrollers today and probably always will be. It only takes 2 pins,
Rx Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU
pins are very precious. It also doesn't even require a UART in the MCU,
though many have them. So *any* MCU w/ 2 free pins can use RS-232 to talk to
the outside world.
This is what stty ttymon exist for. But it doesn't seem to work and
appears to have been broken for some time as Solaris 10 has the same problem.
Nemeth et al note Solaris serial line discipline is a mess. However, it
appears to be worse than that. It appears to be broken.
I don't think anything at all is wrong with the Solaris line discipline
support. But those writing books can say whatever they want. ;-}
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
--- On Wed, 9/5/12, James Carlson carls...@workingcode.com wrote:
From: James Carlson carls...@workingcode.com
Subject: Re: [OpenIndiana-discuss] stty source code
To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
Date: Wednesday, September 5, 2012, 1:26 PM
Reginald Beardsley wrote:
This is an example of one symptom:
oi%rhb {9} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
oi%rhb {10} stty -onlcr
oi%rhb {11} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
[snip]
As an experiment, try this:
stty -onlcr ; stty -a
You may well find that the output is jagged (due to the lack
of
onlcr), and that the output includes -onlcr.
Well, well...
Apparently /bin/tcsh helpfully resets certain of the tty modes. Can't trust
a user to know what they need. /bin/sh and /bin/csh behave as expected.
What a staggering waste of time. Command line retrieval and editing is nice,
but not at this price.
Sigh...
Reg
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Having established that the stty behavior is a red herring produced by
/bin/tcsh here is a precis of the situation (pwd is /etc):
oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430
oi%rhb {181} pmadm -l
PMTAG PMTYPE SVCTAG FLGS ID PMSPECIFIC
zsmon ttymon tty0 uroot /dev/term/0 b -
/usr/bin/login - msp430 ldterm,ttcompat login: - - - -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0
connected
ok.
ok.
ok.
~
[EOT]
rhb@openindiana:/etc$ stty -a
speed 38400 baud;
rows = 77; columns = 107; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
intr = ^c; quit = ^\; erase = ^h; kill = ^u;
eof = ^d; eol = undef; eol2 = undef; swtch = undef;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^?; lnext = ^v;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff
-parext
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
ixon ixany -ixoff imaxbel
isig icanon -xcase echo echoe echok -echonl -noflsh
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
rhb@openindiana:/etc$ stty olcuc
RHB@OPENINDIANA:/ETC$ TIP U0
connected
ok.
ok.
ok.
~
[EOT]
RHB@OPENINDIANA:/ETC$
Note that I have olcuc onlcr set in ttydefs, but it's not being done. With
italso set in the terminal window it doesn't get applied to the remote host
traffic. (The connect is from the USB adapter)
Communication w/ the remote host is 9600 baud, 8 bits, no parity, one stop bit.
The remote host is returning just NL in its output.
Note: The entries in /etc/remote and /etc/ttydefs are a single line each in
case they appear differently on receipt.
Suggestions? Does anyone see anything wrong w/ the ttydefs line? This is
precisely what I expect ttydefs ttymon to fix. At this point, the only
explanation I can think of is that only inbound traffic passed to /bin/login
gets the effect of the arguments in ttydefs and that they are not applied to
traffic using tip. If that's the case, it's not broken, it's just brain dead.
Reg
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Reginald Beardsley wrote:
Having established that the stty behavior is a red herring produced by
/bin/tcsh here is a precis of the situation (pwd is /etc):
oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430
oi%rhb {181} pmadm -l
PMTAG PMTYPE SVCTAG FLGS ID PMSPECIFIC
zsmon ttymon tty0 uroot /dev/term/0 b -
/usr/bin/login - msp430 ldterm,ttcompat login: - - - -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0
connected
ok.
ok.
ok.
~
[EOT]
rhb@openindiana:/etc$ stty -a
You're running stty on your terminal, not on /dev/term/b.
Try running stty -a /dev/term/b whilst you have the tip running on it.
(or I'm misunderstanding what you're trying to do.)
--
Andrew
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
Thanks. It was a rather daunting array of possibilities. --- On Mon, 9/3/12, Bill Sommerfeld sommerf...@alum.mit.edu wrote: From: Bill Sommerfeld sommerf...@alum.mit.edu Subject: Re: [OpenIndiana-discuss] stty source code To: openindiana-discuss@openindiana.org Date: Monday, September 3, 2012, 11:17 PM On 09/03/12 20:05, Reginald Beardsley wrote: Where does one find the source for the stty in 151a? https://hg.openindiana.org/ check out a copy of illumos-gate from https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/ (which looks like it's OI's copy of illumos-gate) and look in: usr/src/cmd/ttymon - Bill ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
I've cloned the repository but find that the Makefile is expecting state to be set in the shell. Where would I find details on what I need to have set to compile just the things in usr/src/cmd/ttymon Is that possible? I'm really not eager to take on building everything as my OI box is a dual core Atom. Thanks. Reg --- On Mon, 9/3/12, Bill Sommerfeld sommerf...@alum.mit.edu wrote: From: Bill Sommerfeld sommerf...@alum.mit.edu Subject: Re: [OpenIndiana-discuss] stty source code To: openindiana-discuss@openindiana.org Date: Monday, September 3, 2012, 11:17 PM On 09/03/12 20:05, Reginald Beardsley wrote: Where does one find the source for the stty in 151a? https://hg.openindiana.org/ check out a copy of illumos-gate from https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/ (which looks like it's OI's copy of illumos-gate) and look in: usr/src/cmd/ttymon - Bill ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] stty source code
On 09/03/12 20:05, Reginald Beardsley wrote: Where does one find the source for the stty in 151a? https://hg.openindiana.org/ check out a copy of illumos-gate from https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/ (which looks like it's OI's copy of illumos-gate) and look in: usr/src/cmd/ttymon - Bill ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
