EPORTS & TB+

[Greg A. Woods]

In article <473 at mtndew.UUCP> friedl at mtndew.UUCP (Stephen J. Friedl) writes:
> Greg A. Woods writes:
> > 
> > You can't
> > even set HFC with an stty, rather you have to use epstty.  It was a
> > really brain-dead, stupid thing to do, especially after almost every
> > other vendor had used (usually the same) un-used bits in a termio flag
> > to do the same.
> 
> The reason for this is that they wanted to keep the UNIX porting
> base free from port-specific code.  Note that there are not that
> many unused bits in the termio flag, and this is not the best way
> to do it anyway.

Unfortunately there are enough free bits to allow a choice.  Without
the leadership of AT&T by putting such features in the porting base,
we end up with in-compatible flags and manifest constants for
different vendors, making it really difficult to maintain portable
code.  Not only that, but with so many vendors out there who don't
know how to make rs-232 ports work (including, this time, AT&T), we end
up with a lot of broken drivers.  I've been banging my head against
AT&T's minimalist attitude for a long time now.

Even the new getty which comes with EPORTS-1.3 doesn't seem to have
anything to do with HFC, but rather only supports B38400.

> I don't like the epstty approach either, but it's not "brain dead".

I'm not flaming at you Sephen, but I do stick firmly to my position
that the eptermio design (as well as implementation) is brain dead.
Your argument just doesn't stick, especially in light of what has been
required for SysVr4 by POSIX with split speed control.

As for your suggestion that there are better ways to do it, I'm
interested in what you think.  I've been puzzling over these kinds of
things for quite a few years now, and perhaps I'm stuck in a rut.
-- 
						Greg A. Woods

woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA