Often the serial driver is provided by modules such as serial_core.ko and 8250.ko, etc. Note that "8250" is really for the descendants of the now obsolete 8250 UART, such as the 16xxx series of UARTS. Drivers for USB serial ports and multiport cards are often provided as modules. Linux should automatically load any needed module, so in most cases you have nothing to do.
But sometimes you need to configure Linux to load certain modules or gives parameters to the module or to the kernel.
Such parameters may be supplied to certain modules on the command line for the kernel or in /etc/modules.conf or /etc/modprobe.conf. Since kernel 2.2 you don't edit this file but use the program update-modules to change it. The info that is used to update modules.conf is put in /etc/modutils/.
The Debian/GNU Linux has a file named /etc/modutils/setserial which runs the serial script in /etc/init.d/ every time the serial module is loaded or unloaded. When the serial module is unloaded this script will save the state of the module in /var/run/setserial.conf. Then if the module loads again this saved state is restored. When the serial module first loads at boot-time, there's nothing in /var/run/setserial.conf so the state is obtained from /etc/serial.conf. So there are two files that save the state. Other distributions may do something similar.
Serial modules are found in subdirectories of
/lib/modules/.../kernel/drivers/. For multiport cards, look
in the serial subdirectory and/or char. For USB serial,
look in the usb/serial subdirectory. The module,
parport_serial is for PCI cards that contain both serial and parallel
ports.
As a last resort, one may modify the serial driver by editing the source code. Much of the serial driver used to be found in the file serial.c. But it's now spread across other files like serial_core.c and 8250.c. Note that 8250.c includes support for the successors of 8250, namely the 16xxx series such as 16C752 and 16850. The serial module changed names similarly. Note that the module: generic_serial.ko was intended to provide support for other serial modules, but it didn't catch on so it's only used for one multiport serial card.
For info regarding writing of programs for the serial port see Serial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie but that revision is not at LDP. See also the Serial wiki Serial-Programming Wiki
If you have more than 4 (or possibly 2) serial ports, then you must insure that the kernel knows this. It can be done by configuring the kernel when compiling or by a parameter given to the kernel when it starts (boot-prompt or kernel command line).
The kernel configuration parameters:
CONFIG_SERIAL_8250_RUNTIME_UARTS=32 and
CONFIG_SERIAL_8250_NR_UARTS=4 set the maximum number of ordinary
serial ports (UARTs) equal to 4. Distributions often set this
to 4 before compiling. If you have more than 4 ordinary
serial ports, then you need to change the 4 to whatever. If you
kernel has already been compiled with not enough ports you may
override this via the kernel command line for example:
8250.nr_uarts=16 (if serial support built into the kernel). A boot
loader such as lilo or grub can be told to do this. If serial support
is via a module, such as 8250.ko, then give nr_uarts as a parameter to
the module. You may use the command like: modinfo 8250 to see
what parameters the module 8250 (or whatever) will accept.
See the kernel documentation in: Documentation/serial-console.txt. See also: Remote-Serial-Console-HOWTO.
For a text terminal, the RS-232 speeds are fast enough but the usable cable length is often too short. Balanced technology could fix this. The common method of obtaining balanced communication with a text terminal is to install 2 line drivers in the serial line to convert unbalanced to balanced (and conversely). They are a specialty item and are expensive if purchased new.
Normally flow control and/or application programs stop the flow of bytes when its needed. But sometimes they don't. The problem is that output to the serial port first passes thru the large serial buffer in the PC's main memory. So if you want to abort printing, whatever is in this buffer should be removed. When you tell an application program to stop printing, it may not empty this buffer so printing continues until it's empty. In addition, your printer has it's own buffer which needs to be cleared. So telling the PC to stop printing may not work due to these two buffers that continue to supply bytes for the printer. It's a problem with printer software not knowing about the serial port and that modem control lines need to be dropped to stop the printer.
One way to insure that printing stops is to just turn off the printer. With newer serial drivers, this works OK. The buffers are cleared and printing doesn't resume. With older serial drivers, the PC's serial buffer didn't clear and it would sometimes continue to print when the printer was turned back on. To avoid this, you must wait a time specified by setserial's closing_wait before turning the printer back on again. You may also need to remove the print job from the print queue so it won't try to resume.
The IO address of the IBM 8514 video board (and others) is
allegedly 0x?2e8 where ? is 2, 4, 8, or 9. This may conflict (but
shouldn't if the serial port is well designed) with the IO address of
ttyS3 at 0x02e8 if the serial port ignores the leading 0 hex
digit when it decodes the address (many do). That is bad news if you
try to use ttyS3 at this IO address. Another story is that Linux
will not detect your internal modem on ttyS3 but that you can use
setserial to put ttyS3 at this address and the modem
will work fine.
The address of ttyS2 is 3e8-3ef while hard drive ide2 uses 3ee which is in this range. So when booting Linux you may see a report of this conflict. Most people don't use ide2 (the 3rd hard drive cable) and may ignore this conflict message. You may have 2 hard drives on ide0 and two more on ide1 so most people don't need ide2.
This has a race condition between an interrupt and a status register of the UART. An interrupt is issued when the UART transmitter finishes the transmission of a byte and the UART transmit buffer becomes empty (waiting for the next byte). But a status register of the UART doesn't get updated fast enough to reflect this. As a result, the interrupt service routine rapidly checks and determines (erroneously) that nothing has happened. Thus no byte is sent to the port to be transmitted and the UART transmitter waits in vain for a byte that never arrives. If the interrupt service routine had waited just a bit longer before checking the status register, then it would have been updated to reflect the true state and all would be OK.
There is a proposal to fix this by patching the serial driver. But Should linux be patched to accommodate defective hardware, especially if this patch may impair performance of good hardware?