From owner-freebsd-hackers Wed May 24 11:04:09 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19303 for hackers-outgoing; Wed, 24 May 1995 11:04:09 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA19296 for ; Wed, 24 May 1995 11:04:07 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07923; Wed, 24 May 95 11:55:46 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505241755.AA07923@cs.weber.edu> Subject: Re: Cyclades Driver/Multi-port Serial Card To: bde@zeta.org.au (Bruce Evans) Date: Wed, 24 May 95 11:55:46 MDT Cc: jkh@freefall.cdrom.com, julian@ref.tfs.com, bde@freefall.cdrom.com, br\ian@med\iac\ity.com, hackers@FreeBSD.org In-Reply-To: <199505240047.KAA01577@godzilla.zeta.org.au> from "Bruce Evans" at May 24, 95 10:47:56 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > I responded several times. Communications didn't seem to be working, so > I gave up and rewrote the NetBSD driver. Diffs are 100K (2.5 times as > large as the original driver). I intend to make even larger changes so > that all the serial drivers use a common front end. cy.c currently has > about 30K of code (out of 60K total) in common with sio.c. rc.c and > cy.c are very similar. They drive similar Cirrus Logic chips and are > based on sio.c for the non-hardware parts. If you put a common cannonical processing front end on things, then you are a god in my book! My personal preference is for a module that is ldterm type seperable and shared with the console (I have a fetish for Streams). Whatever you do, "Go Team, Go!". > Development was halted by the code freeze about a month ago. The driver > is missing mainly configuration stuff for 16-port boards, sending of > breaks, variation of the fifo threshold at low speeds so that mouses > work OK. It is likely to have some bugs involving misuse of the > hardware "intelligence". Use of ttyinput() limits the benefits to be > gained from hardware intelligence to approximately 0%, and I don't care > much about cooked mode so I don't intend to fix this except when > ttyinput() can be avoided completely. The speed variation idea is interesting; basically it would be a data hiding of an implied switch. The last time FIFO depth was considered regarding mice, it was though that a line discipline would be used (as is used in SunOS and SCO) to set it up. This would make more sense than an implied switch IFF the intent was a devide independent /dev/mouse for the console (a nice goal). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.