Re: Inserting flow-control chars with an mpsafetty kernel

On Tue, 26 Aug 2008 18:01:44 +0200, Ed Schouten <ed_at_80386.nl> wrote:
> * Giorgos Keramidas <keramida_at_ceid.upatras.gr> wrote:
>> After installing the mpsafetty changes it seems that flow-control ^S and
>> ^Q characters cannot be inserted inserted anymore.  I first noticed this
>> when CTRL-S stopped working as 'search-forward' in Emacs, but it seems
>> the same problem exists in /usr/bin/vi, vim, bash and a few other
>> programs that I tested.
>>
>> With a kernel before the mpsafetty changes, I can fire up /usr/bin/vi
>> and type in insert-mode `^V^S'.  This correctly inserts a ^S character.
>> With a kernel from svn revision /head_at_181939 ^V no longer quotes the
>> next byte in vi(1) and other programs.
>
> There is indeed a small problem w.r.t. ^S/^Q characters with the MPSAFE
> TTY code, but it is not so directly involved in the handling of the
> actual characters, but a shortcoming of the pts(4) driver.
>
> There is this way a PTY (master device) can be configured to use `packet
> mode' (TIOCPKT). When this mode is enabled, all data that is read() by
> screen is prepended by a single byte, containing a bit mask of events.
> These events include flush events, but also flags indicating tcsetattr()
> has been called and has toggled VSTART/VSTOP.

[snip explanation of packet mode]

> Screen(1) is a fairly moronic written application, which uses packet
> mode for no sensible reason at all. If you just comment out TIOCPKT in
> /usr/include/sys/ttycom.h and recompile screen(1), your problems are
> gone, right?

I'll give it a try and email back.  Thanks! :)

> There are three ways ways to fix this problem:
>
> - Implement a real packet mode which properly returns the TIOCPKT_*
>   flags. Unlike the previous TTY layer, it is a lot harder to do this
>   with MPSAFE TTY, because it turns the generic TTY code into more
>   bloat.
>
>   The new TTY layer has been designed to be a real front-end for the
>   device driver. There aren't any driver hooks (yet) to detect the
>   events supported by TIOCPKT, because `normal drivers' don't need these
>   event notifications anyway.
>
> - Remove TIOCPKT and TIOCPKT_* to <sys/ioctl_compat.h> and leave it
>   there to die. While there, also move definitions of other awkward
>   commands to this header.
>
> - Both.
>
> I was planning to prepare a changeset soonish, which removes the (in
> my opinion) deprecated ioctl()'s from our header files, so I can let
> the ports folks run a tinderbox to see how much breaks. This should
> give us a good estimation of the best approach.

I can definitely rebuild `screen' with a commented out `TIOCPKT'.  On
the laptop I'm testing FreeBSD stuff I also have about 620 ports that
I can rebuild with `portupgrade -fa' in a day or so.  If you want me to
test a patch that moves TIOCPKT_* to <sys/ioctl_compat.h> please count
me in as a tester.