>Can anyone enlighten me about SXTs under System V? We have them on our
>AT&T 3B5, and I know they're used in shl(1) for "job control". But I
>have no documentation whatsoever, and the shl code makes no sense to
>me. What I'd like to know is as follows:
>1. What *are* they? Are they pseudo-ttys? Pseudo-pseudo-ttys?
They are pseudo-ttys, but not in the Berkeley sense. They are really
virtual terminals, but derived (loosely) from the xt (layers) idea.
Quote:>2. How do you use them?
Well, (if I remember correctly) you use an ioctl (SXTIOCLINK) to get
access to the facility, and another (SXTIOCSWTCH) to switch (i/o) to a
layer. The link ioctl gives one a control channel, to which all
subsequent ioctl's must refer.
The switch character then returns control to the controlling
process (shl(1) is about the only thing I can think of which uses
this), where you can then block/unblock i/o from SXT channels, or
resume i/o to one of these channels, etc. The SWTCH char really makes
the controlling process return from a WAIT ioctl.
Quote:>3. What is the relationship between stty(1)'s SWTCH character and
> sxts? I know it's used to get shl's attention, but what are the
> details? Why doesn't my termio(7) man page discuss this character?
Quote:>4. How useful are sxt's, really? Are they expensive in any sense? Our
> /dev is full of 'em.
I have never really found them useful, but there are those who swear
by them. Besides, I have a DMD running layers anyway :-). I find shl
to be a cheap substitute for job control, mainly as `stopping' is done
by blocking i/o and returning control to another process.
Quote:>5. The kicker: why couldn't I get the Korn Shell to use them to give me
> job control? Using shl indicates that you can control blocking and
My understanding is that by putting each command into a seperate
channel, the i/o at that time (as the process is running) is going to
the process and disappears when the process exits. This breaks
typeahead. Shl takes a simpler method by making the user manually
switch between channels, and so avoids the problem.
Your best bet would just be to play around with them for a while, and
see how they work. I doubt you will be able to find a non-shl use for
them, though. One good point about shl, though is that the
modifications required to implement this job control are just in the
sxt driver and shl itself (which is small), not thrown randomly about
the kernel (I'm not finger pointing, but /proc does seem to be a
better way of getting *real* job control, than you-know-who).
ihnp4!ihdev!pdg This Brain left intentionally blank.