in read() and write(). FNONBLOCK is valid in ioctl() and close().
The bug caused hung ptys when a process talked to itself using nonblocking
i/o and exited while the slave pty had output to flush. ttywait() was
called and hung. Signals didn't work because the process was exiting.
`comcontrol /dev/ttyp0 drainwait 1' worked to terminate the wait. This
shows that comcontrol is not limited to hardware control. It has no i386
or driver dependencies and doesn't belong in src/sbin/i386.
Bruce
through a temporary buffer instead of one character at a time. The old
method takes about 6 usec/char on a 486DX2/66. This is larger than than
the combined interrupt and PIO overhead for a 16550!
This change was first implemented in 1.1.5. It was rewritten for 2.1.
The clist access functions allow a simpler implementation at some cost
in correctness and speed. There needs to be an ungetc() function to
recover from EFAULT, and it wastes time to copy through a temporary
buffer.
Don't snoop on single characters that weren't read due to EFAULT.
Rewrite a snoop comment in my approximation to English.
Undo bogus exportation of ttnread().
1) Preserve old buffer contents when input buffer overflows.
Old code clear buffer and rewrite it again, if !MAXBEL
(for MAXBEL it does right thing :-).
F.e. if you type too long string, last chars passed,
not first ones as expected.
Moreover, it flush output queue too in this case without any needs.
2) Don't do IXOFF, if IGNCR and c==\r, ignore completely.
3) If PARMRK is active and !ISTRIP and char == 0377
put yet one 0377 to distinguish it from parity mark sequence.
POSIX standard (thanx Bruce).
Reviewed by:
Submitted by:
Obtained from:
CVS:
(a) bring back ttselect, now that we have xxxdevtotty() it isn't dangerous.
(b) remove all of the wrappers that have been replaced by ttselect
(c) fix formatting in syscons.c and definition in syscons.h
(d) add cxdevtotty
NOT DONE:
(e) make pcvt work... it was already broken...when someone fixes pcvt to
link properly, just rename get_pccons to xxxdevtotty and we're done
(b) add a function callback vector to tty drivers that will return a pointer
to a valid tty structure based upon a dev_t
(c) make syscons structures the same size whether or not APM is enabled so
utilities don't crash if NAPM changes (and make the damn kernel compile!)
(d) rewrite /dev/snp ioctl interface so that it is device driver and i386
independant
Restore fixes to flushing that were lost in the previous commit.
Clean up snoop changes.
Add my TODO list from 1.1.5. The improvements in 1.1.5 should be "obtained"
first.
Users-beware..
It is tested and working for me but probably have some bugs i
didn't noticed so test it and reply...
It can:
look at what's sent to the user from tty device
snoop on pty's,vty's and serial tty's
It (still) can't:
write to tty
see what user types in local echo mode
It is probably bad styled and
very dependant on tty_pty.c,sio.c and syscons.c
I would be really happy if another ppl would make their
changes because i am not sure this is the best snoop
we can have..but it is good..:)))))
TS_WOPEN state when CLOCAL is toggled from on to off while there
is no carrier. There is no way back, and with sio there is no way
forward either (TS_ISOPEN will never be set again for the current
open). This bug was observed in 1.1 and was fixed in 1.1.5.
operation of each clist. Limit the growth of each clist. Clists
can only grow larger than the reserved minimum if there are free
cblocks in a shared pool. The size of this pool is now fixed
(this could be improved). The reserved and maximum sizes are more
carefully allocated for slip and ppp, depending on the mtu. A maximum
MTU of 16384 is now enforced for ppp.
a clist return with an error. There are some clist starvation/deadlock
bugs elsewhere and killing clist hogs didn't help because the breaks
only exited from the inner loops.
a tty.
Note that this might conflict with the collateral use of TS_WOPEN, but
for the moment I can find no problems associated with this. (TS_WOPEN
will likely go away in the future anyway). This should be looked at
again in the future (the potential problem is that the cblock pool
may either run out or accumulate too many cblocks).
