Date: Wed, 31 Jan 1996 10:51:11 +1000 (AEST) From: Greg Ungerer <gerg@stallion.oz.au> To: Terry Lambert <terry@lambert.org> Cc: gerg@stallion.oz.au, hackers@freebsd.org Subject: Re: Multi-Port Async Cards Message-ID: <9601311051.aa00088@cluster.stallion.oz.au> In-Reply-To: <199601302123.OAA07399@phaeton.artisoft.com> from "Terry Lambert" at Jan 30, 96 02:23:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > >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. > OK, I see your point. I neglected to even consider conventional "dumb" boards as part of the picture. (Less than low end :-) [snip] > > >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)? The host driver code will be available in source form. It has been available for Linux for about 12 months now. The slave (that is download) code will only be available in binary. It was just easier to use Stallions standard image, since it has just about everything you will ever need to do in it. And in any case most people will not have the tools to build it... The interface is documented, the header file included in the Linux package cdk.h has most of the programing details. Its pretty light on real description of how the interface works. Nobody much has been interrested up to now... > > 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). Well, the boards we are talking about here don't use DMA, but rather use a Dual Ported Memory arrangement, a shared memory region that is visible to both the host and slave processors. For SCO it is better to bypass CLISTS all together. The most common solutions are to implement your own line discipline, or simply bypass the stardard one all together when appropriate. Certainly it would be nice if the line discipline had the ability to "negioate" processing modes with the driver - better than trying to hack around and bypass it. The SVR4 streams ldterm module can sort of do this. So that it can doing nothing but pass data messages through in an ideal case. Obviously for the true intelligent boards you want to be able to do as few data copies as possible - ideally direct from user space into the boards shared memory buffers... > > > >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. Absolutely. No point in each driver re-doing this. Seeya Gerg --------------------------------------------------------------------------- Greg Ungerer EMAIL: gerg@stallion.com Stallion Technologies Pty Ltd PHONE: +61 7 3270 4271 33 Woodstock Rd, Toowong, QLD 4066, Australia FAX: +61 7 3270 4245
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9601311051.aa00088>