From owner-freebsd-hackers  Tue Oct 10 03:09:59 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id DAA26712
          for hackers-outgoing; Tue, 10 Oct 1995 03:09:59 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA26698
          for <hackers@freebsd.org>; Tue, 10 Oct 1995 03:09:46 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA15689; Tue, 10 Oct 1995 20:09:36 +1000
Date: Tue, 10 Oct 1995 20:09:36 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510101009.UAA15689@godzilla.zeta.org.au>
To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au
Subject: Re: non-sio UART driver
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?

>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.

>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.

>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.

Bruce