Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1380 ; Tue, 23 Feb 93 14:37:49 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usenet.ins.cwru.edu!agate!gaia.CS.Berkeley.EDU!cgd
From: cgd@gaia.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Release of my serial driver for patchkit 0.2.1
Date: 15 Feb 1993 06:27:07 GMT
Organization: Kernel Hackers 'r' Us
Lines: 267
Distribution: world
Message-ID: <1lnd3r$b74@agate.berkeley.edu>
NNTP-Posting-Host: gaia.cs.berkeley.edu
i've updated my serial driver package so that it works with patchkit 0.2.1...
enclosed is the readme, and in the following message is the driver itself.
chris
========== CUT HERE FOR README
The Serial Driver Strikes Back...
This is another release of my serial driver hacks.
Basically, for this one, I was smarter than to try to get
my previous work to work right, and started again from
a "stock" serial driver, and added and fixed things as
necessary, to get both multiport and bidirectional port
support in.
This release incorporates the bug fixes suggested by the
net, and, as far as i can tell, works properly. It's not
been extensively tested, so it's still beta, but i've
got it running right here driving my SLIP connection,
my mouse, another modem (dial-in and dial-out), my
laser printer, and a VT220... 8-)
This version has also been updated to work with the
new "official unofficial" patchkit, v. 0.2.1, and includes
the bug fixes to the previous driver which have been
posted to the net recently.
The multiport support is designed to work with AST multiport
cards, and other ISA multiport cards which conform to the
programming spec of that type of card. (This includes
the KW-531A...)
HOW TO GET IT:
This package will be available on:
agate.berkeley.edu
128.32.155.1
pub/386BSD/386bsd-0.1/unofficial/cgd/com-beta.0.2.1.tar.Z
and
ref.tfs.com
140.145.245.251
/usr/src/sys.extras/cgd-com-ports/com-beta.0.2.1.tar.Z
~cgd/com/com-beta.0.2.1.tar.Z
HOW TO INSTALL IT:
This is meant to be installed on a stock source tree,
with all of the "000" series of patches from the
"patchkit-0.2.1.tar.Z" installed. (This is the latest
patchkit as of this writing, and is available from
agate in pub/386BSD/386bsd-0.1/unofficial/patch-kit,
among other places.) Obviously, you can have more changes
to the standard source tree than this, but you might
need to apply the some of the patches in "diffs" by hand.
su to root, then do all of the following:
patch -p < diffs
(Note that this assumes that the sources you want to
apply it to are under /usr/src.)
cd to / and untar comcontrol.tar
(This places the sources for the "comcontrol" program
in /usr/src/sbin.)
cd /usr/src/sbin/comcontrol ; make ; make install clean
and recompile your kernel.
(An example of a kernel config file which uses the
special capabilities of this driver is in SAMPLE.CONFIG.
This example file also includes some useful comments
explaining how things work.)
WHAT TO DO NEXT:
Here's where it gets tricky; depends on what *you* want to do.
You'll probably have to do at least the following:
(1) make some new device nodes for "callout" devices
(see "MAKING DEVICE NODES" below)
(2) set up ports as bidirectional, by adding a few lines to
/etc/rc.local (see "USING comcontrol" below)
if you're familiar with SunOS's bidirectional serial ports,
you'll get this fairly quickly. otherwise, here's a general
explanation:
Serial ports are useful, and modems are too. Sometimes you
only own one modem, but want to use it for both calling out
*and* receiving incoming calls. Normally, that'd be hard
to do, but with bidirectional serial ports, it becomes easy.
To do this, you'd simply set the port to be bidirectional,
and set up /etc/ttys to put a getty on that port's "incoming"
side. The getty would not actually become "active" until
it received a signal that a carrier was detected by the
modem on the port. If the getty is not active, then you
can use "tip" or another dialout program to get out through
the ports "callout" side. Each of these "sides" is a different
device in /dev, and coordination among the two "sides" of
the port is handled in the driver.
MAKING DEVICE NODES:
The important info:
character device
major number 8
minor number 0..127 for "incoming" sides of ports,
or for use when bidirectionality is disabled
minor numbers 128..255 for the corresponding "callout"
sides of the ports, but only when bidirectionality
is enabled.
I suggest the naming be as follows:
incoming ports: tty00, tty01, tty02, etc.
callout ports: cua00, cua01, cua02, etc.
If you use those names for the incoming ports, ps and other
related utils work right, otherwise they don't work in the
way one would expect.
to do this the commands you want are like:
mknod c 8 0 /dev/tty00
mknod c 8 1 /dev/tty01
mknod c 8 2 /dev/tty02
.
.
.
mknod c 8 128 /dev/cua00
mknod c 8 129 /dev/cua01
mknod c 8 130 /dev/cua02
.
.
.
USING comcontrol:
comcontrol works as follows:
if you want info about the bidirectional status of
a port, you say:
comcontrol <dev name>
where <dev name> is the name of the device node for the incoming
side of the port.
if you want to set the bidirectional status of the port,
you say:
comcontrol <dev name> bidir
to enable bidirectionality, or
comcontrol <dev name> -bidir
to disable it. Again, <dev name> is the name of the device
node for the incoming side of the port. It is strongly recommended
that you do *not* change the bidirectional status of a port
while there are programs using the port... (read that as:
if you do, and it breaks, don't yell at me; that's a really
weird thing to do.)
All users with read access to the port device node can
use comcontrol to get the port's status. Only root
can set a port's status.
The standard way to use comcontrol is to put invocations of it
in the /etc/rc.local startup script.
For instance, for the machine described by the SAMPLE.CONFIG
file, the following lines are in the rc.local:
#/sbin/comcontrol /dev/tty00 bidir # mouse -- unidirectional
#/sbin/comcontrol /dev/tty01 bidir # terminal -- unidirectional
/sbin/comcontrol /dev/tty02 bidir # printer -- bidir, in case i'm bored
/sbin/comcontrol /dev/tty03 bidir # modem 1
/sbin/comcontrol /dev/tty04 bidir # modem 2
note that ports default to unidirectional.
KERNEL CONFIG OPTIONS:
COM_IGNOREFIFO:
Use this if you want the driver to completely
IGNORE the FIFOs on 16550 UARTS. This can
help get your serial ports working, if their
UARTS are old and the probe for the FIFOs screws
them up. If you've got a UART with FIFOs
(i.e. a 16550), using this option will be
a big performance hit, and will increase the loss
of incoming characters.
COM_MULTIPORT:
Use this to enable multiport serial board handling.
(Interrupt sharing by non-multiport boards is *NOT*
supported. Sorry.) This option also affects
the way that serial interrupts are processed, and I'd
recommend that it always be defined when using this
driver.
COM_BIDIR:
Enable the bidirectional port features of the serial
driver. If you don't include this option in your
kernel config, "comcontrol" is a waste of time;
w/o this option, the ports *can't* be bidirectional.
With this option enabled, ports default to being
unidirectional, but comcontrol can change that.
Without this option, you'll see a *slight* performance
boost, but this boost is so slight (i.e. just a few
instructions, that is, not noticable) that I'd
reccomend that you leave it enabled unless you've
good reason not to.
BUGS FIXED IN THIS RELEASE:
(These are the patches to the previous release which
are included in this release.)
com-beta.patch01:
SLIP reliability and FIFO trigger level fixes
(by me)
com-beta.patch02:
interrupt enable and dialout carrier fixes
(by Guido van Rooij, guido@gvr.win.tue.nl)
com-beta.patch03:
16550-compatible chip initialization delays
(by Dwight E. Cass, dec@nrtc.northrop.com)
THANKS TO:
Brad Huntting and John Kohl, for making a fast "base" serial driver.
Brian Litzinger for doing a basic (thought flawed) version of
multiport-board support.
All of the people who've helped debug this beast!!!
BUGS TO:
Chris Demetriou
cgd@agate.berkeley.edu
(otherwise known as the latest "author" of this beast... ick!)
Enjoy, and I hope you find this useful...
Chris
--
Chris G. Demetriou cgd@cs.berkeley.edu
MENTALLY CONTAMINATED and proud of it!