Date: Tue, 30 Jan 1996 14:23:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gerg@stallion.oz.au (Greg Ungerer) Cc: hackers@freebsd.org, gerg@stallion.oz.au Subject: Re: Multi-Port Async Cards Message-ID: <199601302123.OAA07399@phaeton.artisoft.com> In-Reply-To: <9601301121.aa20625@cluster.stallion.oz.au> from "Greg Ungerer" at Jan 30, 96 11:21:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >The difference between "high end" and "low end" operation of a "high end"
> >board is nothing more than software.
>
> Hmmm, well perhaps from some vendors this is the case. But, Stallions low
> and high end offerings use very different hardware architectures. The low
> end relies on "smart" UARTS, with FIFOs, automatic flow control, etc, to
> give reasonable cost/performance trade offs. While the high end uses off-
> board CPU's and large memory buffers for much better performance, at more
> cost.
We are only interested in "high end" boards for this discussion.
Programming information for "low end" boards is available.
Let me restate:
1) A "high end" board needs cooperation of the driver, and
generally programming information from the board vendor
for it to give you any benefit above a "low end" board.
2) A "high end" board can have a driver written for it without
this information, but such a driver *cannot* take advantage
of the undocumented features of the board.
SO: The difference between "high end" and "low end" operation of a
"high end" board is nothing more than software.
> >It is possible to download portions of the tty subsystem, such as flow
> >control (in and out of band) and cannonical processing to a "high end"
> >board. To do so, you need serious documentation on the board.
>
> Yep, that is what the Stallion medium to high end stuff does. The drivers
> I did for Linux for these types of boards uses the same off-board executable
> image as the Stallion supported operating systems. I just wrote the host
> drivers to the specification of their shared memory interface. I will do
> the same thing for FreeBSD drivers for these boards.
This is a cool thing you are doing. Are the drivers going to be binary
only, or are they going to be source (thus effectively documenting this
interface)?
It is likely that given sharing of cannonical processing code between
interfaces, we will want to provide out own download, or at least
pound the interface together (for instance, I believe that the SCO
Xenix code uses CLIST structs as DMA transfer target areas, but we
don't have that so we will need to provide a different transfer
mechanism).
> >Generally vendor supplied drivers (at least in the SCO world) have
> >had a bunch of other "add-ons", like "transparent print" using a finite
> >state automaton based on the attached terminal type to ensure printer
> >data transfers only occur with the terminal in ground state in the
> >terminals internal escape sequence processing automaton. This takes
> >the place of atomic I/O processing of escape sequences and/or dictating
> >allowable terminal types from a set of allowable types (ala DEC's VMS
> >terminal I/O processing).
>
> Yeah that is true - that is why I wimped out and didn't do it for Linux
> or FreeBSD drivers. So far nobody has asked for it... Does not GNU mscreen
> do most of this at application level?
No.
I might do the work if I get motivated enough. I did much of the original
emulation code in the TERM product (Century Software)... the SCO console,
VT220, Televideo, Wyse, Qume, and IBM emulations were mostly mine.
I'd prefer that it be common and board independent (ie: a feature of the
OS, not a feature of the driver) in any case.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601302123.OAA07399>