cpw%sneezy@lanl.gov (C. Philip Wood) (04/14/88)
Apparently, 'getty' can be told, via 'gettytab' whether to do "any parity", "even parity" or "odd parity". Depending on this setting, it will mask off the parity bit, or honor the appropriate parity on input. Output is another story. It appears that there are only two choices on output, odd or even parity. However, our site has chosen to require it's hosts to not generate parity. Most of our terminals can be configured to "8 bit none" which means to them to mask off the high order parity bit and output the appropriate character image. However, there are some vendor terminals and emulators which barf on characters with parity (odd or even) if configured to "8 bit none" mode. They have an extended character set and actually try to output the corresponding "graphic" for an ascii character with a parity bit set. Note: I have been told that the other operating systems we have here can be told to (or do) not generate parity. So, my question(s) are: 1. Is my analysis correct. If not, please correct. 2. What can be done short of a kernel change to provide a solution? 3. If there is no easy solution. Should UNIX be modified so that it will not (optionally) generate parity on output?
chris@mimsy.UUCP (Chris Torek) (04/14/88)
In article <12952@brl-adm.ARPA> cpw%sneezy@lanl.gov (C. Philip Wood) writes: >... It appears that there are only two choices [for] output, odd or >even parity. ... our site has chosen to require its hosts to not >generate parity. ... there are some vendor terminals and emulators >which ... have an extended character set ... [and print odd graphics >when receiving characters with parity bits] >2. What can be done short of a kernel change to provide a solution? Very little. You can run in `raw' mode, but that is entirely unsatisfactory, or in `litout mode', which is somewhat less so. If you have 4.3BSD you can run in `litin + litout' mode and write a user level program to mangle, er, manage, parity over pty lines, and use that to work around the problem, but this is ugly and slow. >3. If there is no easy solution. Should UNIX be modified so > that it will not (optionally) generate parity on output? The 4BSD drivers should be thrown out entirely (`thrown aside with great force' :-) ). Berkeley CSRG are working on a POSIX-like tty interface, which will no doubt fix all this, but that is not likely to emerge for some time. Sun may provide something useful soon, what with their AT&T deal. Some vendors (e.g., Pyramid) provide a SysV interface (Pyramid's scheme is convoluted but useable), which can (or should be able to) do what you need. In short, it can be done, but it may not be easy. If you need an immediate solution, hack the kernel, but be prepared to deal with the resulting mess. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ks@pur-ee.UUCP (Kirk Smith) (04/14/88)
In article <12952@brl-adm.ARPA> cpw%sneezy@lanl.gov (C. Philip Wood) writes: >It appears that there are only two >choices on output, odd or even parity. As it turns out, if you use :rw:ap: in the gettytab description, it will go into cbreak mode, which happens to only use 7 bits for your output data, and will hopefully output no parity. Some device drivers have historically not handled ANYP "correctly" on output. That is, even with ANYP set in the tty mode word, they default to some sort of parity on output (usually EVEN). This appears to be a historical problem and was discussed some time ago. We have those terminals too, and we set up gettytab like that and "fixed" the device driver for the port board. It has worked fine for about 2 months and we have had no problems with it thus far. Kirk Smith
guy@gorodish.Sun.COM (Guy Harris) (04/15/88)
> >2. What can be done short of a kernel change to provide a solution? > > Very little. You can run in `raw' mode, but that is entirely > unsatisfactory, or in `litout mode', which is somewhat less so. If you > have 4.3BSD you can run in `litin + litout' mode and write a user level > program to mangle, er, manage, parity over pty lines, and use that to > work around the problem, but this is ugly and slow. If the goal is not to permit deliberate access to the extended character set, but merely to prevent unintended access to the extended character set (i.e., to prevent a character from getting the 8th bit turned on by the serial port hardware and thus to be transformed into an extended character), they can turn on PASS8 in 4.3BSD. This disables stripping of input to 7 bits, but unfortunately doesn't disable stripping of output to 7 bits; it also puts the serial port hardware into "8 bits, no parity" mode. > >3. If there is no easy solution. Should UNIX be modified so > > that it will not (optionally) generate parity on output? > > The 4BSD drivers should be thrown out entirely (`thrown aside with > great force' :-) ). Berkeley CSRG are working on a POSIX-like tty > interface, which will no doubt fix all this, but that is not likely to > emerge for some time. I presume it's POSIX-compatible, not just "POSIX-like". > Sun may provide something useful soon, what with their AT&T deal. Actually, we'll provide it with SunOS 4.0. 4.0 has a tty driver, development of which was started *before* the AT&T deal, that has an S5/POSIX style "ioctl" interface with a streams module pushed atop it that maps V7/BSD "ioctl"s into S5/POSIX-style "ioctl"s. (All of the BSD user interface features, except for the "delayed suspend" character and the LTILDE bit, are implemented in the POSIX-style "ioctl"s. I say "POSIX-style" here because those features are implemented according to a scheme that appeared in early POSIX drafts; the scheme was originally proposed by Clem Cole, Jim McGinness, and somebody from Tektronix.) Basically, output is never stripped to 7 bits by the software; the only such stripping is done by the hardware if you set the character width to 7 bits. Input may or may not be stripped, depending on the setting of the ISTRIP mode. If you set PASS8, the "ioctl" mapper will turn this into "8 bits, no parity, no input stripping" mode, and give you a full 8-bit data path. We also changed "getty" so that you can specify a "p8" capability in "gettytab"; this causes PASS8 to be turned on.
chris@mimsy.UUCP (Chris Torek) (04/15/88)
In article <49535@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >... turn[ing] on PASS8 in 4.3BSD ... puts the >serial port hardware into "8 bits, no parity" mode. Good point. This will probably solve the original problem. >>... Berkeley CSRG are working on a POSIX-like tty interface [me] >I presume it's POSIX-compatible, not just "POSIX-like". [guy] I said `POSIX-like' because, strictly speaking, POSIX does not exist yet. There is no absolute guarantee that the ultimate POSIX standard will look anything at all like what we have now---not that I expect anything drastic to happen. Some minor tweak might make the interface somehow incompatible, however; hence the weasel wording. >> Sun may provide something useful soon, what with their AT&T deal. >Actually, we'll provide it with SunOS 4.0. ... >Basically, output is never stripped to 7 bits by the software; the only such >stripping is done by the hardware if you set the character width to 7 bits. There is some confusion here when you get to simplistic hardware that does not do parity at all. In that case I would assume the software will emulate the nonexistent hardware stripping. (Actually, if you set the `device' to 7 bits, no parity, the driver is obliged to fake up a parity bit [1 or 0, I forget] to emulate a stop bit, given the lack of anything better, on such hardware. Fortunately, we have no such hardware around here, and I doubt Sun sells any either. It would be nice if asynch protocols were not so messy.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@gorodish.Sun.COM (Guy Harris) (04/15/88)
> >>... Berkeley CSRG are working on a POSIX-like tty interface [me] > > >I presume it's POSIX-compatible, not just "POSIX-like". [guy] > > I said `POSIX-like' because, strictly speaking, POSIX does not exist > yet. True. Unfortunately, "POSIX-like" may connote "we've lifted some ideas from POSIX, but we have no committment to make it particularly look like POSIX" rather than "we'll try our best to make it look like POSIX"; I believe the latter is what was intended. (The same problem exists with "UNIX-like", a term that is much overused, especially when used to refer to systems derived from AT&T code....) > >Actually, we'll provide it with SunOS 4.0. ... > >Basically, output is never stripped to 7 bits by the software; the only such > >stripping is done by the hardware if you set the character width to 7 bits. > > There is some confusion here when you get to simplistic hardware that > does not do parity at all. In that case I would assume the software > will emulate the nonexistent hardware stripping. (Actually, if you set > the `device' to 7 bits, no parity, the driver is obliged to fake up a > parity bit [1 or 0, I forget] to emulate a stop bit, given the lack of > anything better, on such hardware. Fortunately, we have no such > hardware around here ... Are you certain? The 4.3BSD VAX "vax/cons.c" console driver does use "partab" when transmitting to the console. "partab" dates back to the aforementioned flavor of hardware, namely various DL-11 flavors on PDP-11 UNIX. Actually, what I should have said is "output is never stripped to 7 bits by the line discipline; the only such stripping is done by the hardware or the low-level device driver if you set the character width to 7 bits." If you have hardware that doesn't do parity generation or checking, the driver would do the former (and perhaps the latter, if anybody cares) and present to the line discipline the appearance of a device that does it. ("line discipline" refers, in systems such as SunOS 4.0 that use streams for the tty subsystem, to the streams module that performs the functions of a line discipline in systems that don't use streams for the tty subsystem.)
allbery@ncoast.UUCP (Brandon Allbery) (04/24/88)
As quoted from <11057@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek): +--------------- | In article <12952@brl-adm.ARPA> cpw%sneezy@lanl.gov (C. Philip Wood) writes: | >... It appears that there are only two choices [for] output, odd or | >even parity. ... our site has chosen to require its hosts to not | >generate parity. ... there are some vendor terminals and emulators | | great force' :-) ). Berkeley CSRG are working on a POSIX-like tty | interface, which will no doubt fix all this, but that is not likely to | emerge for some time. Sun may provide something useful soon, what with | their AT&T deal. Some vendors (e.g., Pyramid) provide a SysV interface +--------------- [Just in case anyone's interested...] System V has independent parity handling on input and output, with the exception that the same parity setting (odd or even) must be used for both if parity is enabled. Input modes: inpck check parity on input istrip strip parity before passing to program parmrk mark parity errors with out-of-band characters (or special character escapes) ignpar if set, parity errors are ignored; otherwise they are passed on as NUL (ASCII 0) Control modes: parenb enable output parity generation parodd if set, odd parity is used for parenb and inpck; otherwise, even parity is used (Someone answer me a dumb question: what good is parity checking on a pty?) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery Delphi: ALLBERY MCI Mail: BALLBERY