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. It was revised in 1999 by Vern Hoxie but it's 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. 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?