From owner-freebsd-hackers Mon Jan 29 19:09:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA13461 for hackers-outgoing; Mon, 29 Jan 1996 19:09:42 -0800 (PST) Received: from easy.stallion.com (easy.stallion.com [204.31.184.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA13454 for ; Mon, 29 Jan 1996 19:09:39 -0800 (PST) Received: from cluster.stallion.oz.au by easy.stallion.com id ac04640; 29 Jan 96 19:09 PST Subject: Re: Multi-Port Async Cards To: hackers@freebsd.org Date: Tue, 30 Jan 1996 11:21:43 +1000 (AEST) From: Greg Ungerer Cc: Greg Ungerer X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9601301121.aa20625@cluster.stallion.oz.au> Sender: owner-hackers@freebsd.org Precedence: bulk Terry Lambert writes: >> >I think no. Linux have just the same problems with multiport cards as >> >FreeBSD. From technical point of view I myself would prefer some >> >Digiboard, but because of a very restrictive policy of this company >> >on the design of inner parts of card design it's nearly impossible to >> >implement a good driver without a NDA. To go back a couple points... I would say (having written multiport drivers for both Linux and FreeBSD) that the problems are the same. >> >> How far away is the driver from being "good"? I have no problem with >> NDAs? > >Neither do I, if someone else writes the driver. > >> Does this hold for all of their boards? or only certain high end ones? > >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. > >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. > >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? 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