From owner-freebsd-hackers Tue Oct 10 11:27:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA29061 for hackers-outgoing; Tue, 10 Oct 1995 11:27:50 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA29055 for ; Tue, 10 Oct 1995 11:27:46 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10775; Tue, 10 Oct 1995 11:25:03 -0700 From: Terry Lambert Message-Id: <199510101825.LAA10775@phaeton.artisoft.com> Subject: Re: non-sio UART driver To: bde@zeta.org.au (Bruce Evans) Date: Tue, 10 Oct 1995 11:25:03 -0700 (MST) Cc: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au In-Reply-To: <199510101009.UAA15689@godzilla.zeta.org.au> from "Bruce Evans" at Oct 10, 95 08:09:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2102 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > As I dribbled a little while ago, I need to talk to a multidrop serial bus > >using a standard serial port. > > What's a multidrop serial bus? You know; like an Altos 2000. 8-). Basically, it uses an RS422 interface to talk to a box with multiple serial ports. The Altos and PrimeOS driver problem that these had was that there was a single input/output request queue per port -- just like VMS TTY I/O in VMS 4.2 and below. Basically, if you did a blocking read, subsequent operations, including writes, could not complete until the read completed. Quite bogus. Watch out for the single queue bug if you write/port a driver for the things. > >The nature of the protocol and interface mechanism for the bus tend to > >indicate to me that I don't want to use the sio driver and hack on that, > >but perhaps to make a copy and cut it severely down to size. > > If you need to do any normal serial i/o to a 16x50 then I suggest adding > to sio. It's not; it's a muxed 422/424 connection to multiple uarts in a fan-out box. Actually, it'd be fun to use the ports themslves as 1-2Mb/S serial interfaces without the fan-out units attached. 8-). > >Given this, how should I avoid the MCR_IENABLE conflict that's > >introduced by sioprobe() forcing the standard four ports' interrupts off? > > >(Perhaps just reenable interrupts on open?) > > That would work if the new device is probed after sio. This is probably the wrong way to probe it. > >Infact, given that this is really a packet-based network, would I be better > >of abandoning all of the tty interface gumpf in the sio driver and doing > >everything via ioctl() calls? (or something equally bogus?) > > If there are only protocol differences, then use a line discipline. Slip > and ppp are good examples. Yes. Integrate it as a serial interface with a different line discipline that means demux for the fan-out on the other end. Then probe it as if it were just another serial card. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.