*BSD News Article 10084


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA7179 ; Mon, 18 Jan 93 10:49:25 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!spool.mu.edu!agate!eden.CS.Berkeley.EDU!cgd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: [386BSD] New release of my improved serial driver
Date: 19 Jan 1993 08:09:54 GMT
Organization: Kernel Hackers 'r' Us
Lines: 246
Distribution: world
Message-ID: <1jgd0i$t2t@agate.berkeley.edu>
NNTP-Posting-Host: eden.cs.berkeley.edu
Summary: it's back, and it's better...
Keywords: 386bsd, com, serial, UART, 16450, 16550

[ Here's the README.  to keep millions of people from asking for it to
  be posted, i've taken the liberty of posting it in a following message,
  as well.  hope you enjoy it!  8-) -- cgd ]

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

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

and

	ref.tfs.com
	140.145.245.251
	/usr/src/sys.extras/cgd-com-ports/com-beta.tar.Z
	~cgd/com/com-beta.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.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.

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 the people who've encouraged me and sent me bug reports,
	especially ones like Andrew Chernov, who not only found
	some really weird bugs, but were vocal enough about them
	that I decided to do something about them... 8-)

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

"Sometimes it is better to have twenty million instructions by
        Friday than twenty million instructions per second." -- Wes Clark