Often the serial driver is provided as a module. Parameters may be supplied to certain modules in /etc/modules.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 here 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.
One may modify the serial driver by editing the source code. Much of the serial driver is found in the file serial.c. For info regarding writing of programs for the serial port see Serial-Programming-HOWTO (revised in 1999 by Vern Hoxie but not at LDP. Get it from scicom.alphacdc.com/pub/linux)
See the kernel documentation in: Documentation/serial-console.txt. Kernel 2.4+ has better documentation. See also "Serial Console" in Text-Terminal-HOWTO.
For a text terminal, the EIA-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. One example is printing to printer on the serial port. If you want to instantly stop printing you may try turning off the printer. With older versions of the serial driver, the printer would attempt to resume printing if you turned the printer back on again (before the time specified by closing_wait of setserial had expired). The attempt to resume would happen even if you used a command to stop the printing. The problem was that once the printer software sent bytes to the large serial buffer to be printed, these bytes were not removed from this buffer when the print job was canceled. One way to remove them (for newer serial drivers) is to simply turn off the printer. This will drop all modem control signals from the printer and empty the buffer. Modern printers have large buffers and often a button on the printer to empty the buffer.
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.
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?