(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).