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