Most info on getty has been moved to Modem-HOWTO with a little info on the use of getty with directly connected terminals now found in Text-Terminal-HOWTO.
A few Linux programs (and one "file") will monitor various modem control lines and indicate if they are positive (1 or green) or negative (0 or red).
irqtune will give serial port interrupts higher
priority to improve performance.hdparm for hard-disk tuning may help some more.
This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
If you have a Laptop (PCMCIA) don't use setserial until you
read
Laptops: PCMCIA.
The term PnP means Plug-and-Play. All serial ports on the PCI bus are PnP and many on the ISA bus are also PnP. Linux software with the term "pnp" in it is usually only for the ISA bus. The PCI bus is inherently PnP so sofware for dealing with PnP on the PCI bus usually contains the term "pci" but not "pnp".
setserial is a program which allows you (or a shell script) to
talk to the serial device driver software. You may use it to tell the
device driver how the hardware is phsically set (I/O addrees, IRQ,
etc.). But normally, the device drivers finds out this infomation
itself so that you don't need to use setserial. But if the device
driver can't find a serial port (or perhaps gets the IRQ wrong) and
you can find out this infomation while the driver can't, then
setserial is essential. How to find serial ports is covered
elsewhere, and in a minority of cases, setserial will be useful
to help find them.
setserial permits you (or a script) to configure the serial port
by telling the device driver the I/O address of the serial port, which
interrupt (IRQ) is set in the port's hardware, what type of UART you
have, etc. The name setserial is somewhat of a misnomer since it
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
them in the driver software. And the driver naively believes that
what setserial tells it has already been set in the hardware.
Since the device driver is considered to be part of the kernel, the
word "kernel" is often used in other documentation with no mention
made of any "serial driver".
Some distributions (and versions) set things up so that setserial is
run at boot-time by an initialization shell script (usually in the
/etc directory tree). In other cases, you have to take some action to
run setserial at boot-time. setserial will not work without
either serial support built into the kernel or loaded as a module.
The module may get loaded automatically if you (or a script) attempt
to use setserial.
In addition to using setserial to configure, setserial can
show you how the driver is currently configured (set). Hopefully, the
hardware is set the same. In addition, it can be made to probe the
hardware I0 port addresses to try to determine the UART type and IRQ,
but this has severe limitations. See
Probing. Note that it can't set the IRQ or the port address
in the hardware of PnP serial ports (but the plug-and-play features of
the serial driver may do this). It also can't directly read the PnP
data stored in configuration registers in the hardware. But since the
device driver can read these registers, setserial could be
telling you what's in them, or it could be telling you what
setserial had previously (and perhaps erroneously) told the
driver. There's no way to know for sure without doing some other
checks.
The serial driver (for Linux 2.4+) looks for a few "standard" legacy
serial ports, for PnP ports on the ISA bus, and for all supported port
hardware on the PCI bus. If it finds these OK then there's no need to
use setserial. The driver doesn't probe for legacy IRQs and may
get these wrong.
Besides the man page for setserial, check out info in
/usr/doc/setserial.../ or /usr/share/doc/setserial.
It should tell you how setserial is handled in your distribution of
Linux. While setserial behaves the same in all distributions,
the scripts for running it, how to configure such scripts (including
automatic configuration), and the names and locations of the script
files, etc., are all distribution-dependent.
If a serial module gets unloaded, the changes previously made by
setserial will be forgotten by the driver. But while the driver
forgets it, a script provided by the distribution may save it in a
file somewhere so that it can the restored if the module is reloaded.
There once was a problem with slow serial printers (especially the old ones of the 1980s). The printing program would close the serial port at the "end" of printing well before all the characters from the large serial buffer (in main memory) were sent to the printer. The result was a truncated print job that didn't print the last paragraph or last page, etc.
But the newer lprng print program (and possibly other printing
programs) keeps the port open until printing is finished so "problem
solved", even if you're using an antique printer. Setserial can
modify the time that the port will keep operating after it's closed
(in order to output any characters still in its buffer in main RAM).
This is done by the "closing_wait" option per the setserial man
page. For "bad" software that closes the port too soon, it might also
be needed at speeds above 1200 if there are a lot of "flow control"
waits.
setserial commandRemember, that setserial can't set any I/O addresses or IRQs
in the hardware. That's done either by plug-and-play software (run by
the driver) or by jumpers for legacy serial ports. Even if you give
an I/O address or IRQ to the driver via setserial it will not set
such values and assumes that they have already been set. If you give
it wrong values, the serial port will not work right (if at all).
For legacy ports, if you know the I/O address but don't know the IRQ you may command setserial to attempt to determine the IRQ.
You can see a list of possible commands by just typing setserial
with no arguments. This fails to show you the one-letter options such
as -v for verbose which you should normally use when troubleshooting.
Note that setserial calls an IO address a "port". If you type:
setserial -g /dev/ttyS*
"UART: unknown" it
probably means that no uart exists. In other words, you probably have
no such serial port and the other info shown about the port is
meaningless and should be ignored. If you really do have such a
serial port, setserial doesn't recognize it and that needs to be
fixed.
If you add -a to the option -g you will see more info although few
people need to deal with (or understand) this additional info since
the default settings you see usually work fine. In normal cases the
hardware is set up the same way as "setserial" reports. But if you are
having problems there is a good chance that setserial has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values you've supplied to the driver. They will also be officially
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command (Debian). Of course the serial
port driver will not work correctly (if at all) if you attempt to use
such a port. Thus, when giving parameters to setserial, "anything
goes". Well almost. If you assign one port a base address that is
already assigned (such as 3e8) it may not accept it. But if you use
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
is within the range starting at base address 3e8. Thus the moral of
the story is to make sure your data is correct before assigning
resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file usually restores them when the PC is started
up again. In newer versions, what you change by setserial might get
automatically saved to a configuration file. When setserial runs
it uses the info from the the configuration file. In Debian there are
4 options for use of this configuration file:
setserial reports when the system is first
shutdown and put it in the configuration file. After that, don't ever
make any changes to the configuration file, even if someone has made
changes by running the setserial command on the command line and
then shuts down the system. ("autosave-once" option)setserial detects to the
configuration file. ("autosave" option)In old versions (perhaps before 2000), there wasn't any configuration
file and the configuration was manually set (hard coded) inside the
shell script that ran setserial. See
Edit a script (prior to version 2.15).
You probe for a port only when you suspect that it has been enabled (by PnP methods ,the BIOS, jumbers, etc.), otherwise setserial probing will never find it since its address doesn't exist. Probling is where the software looks for a port at specified I/O addresses. Prior to probing with "setserial", one may run the "scanport" (Debian) command to check all possible ports in one scan. It makes crude guesses as to what is on some ports but doesn't determine the IRQ. It's a fast first start. It may hang your PC but so far it's worked fine for me. Note that non-Debian distributions don't seem to supply "scanport". Is there another scan program?
With appropriate options, setserial can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
is at a different address, then it will probe at that address, etc.
See
Probing
The purpose of such probing is to see if there is a uart there, and if
so, what its IRQ is. Use setserial mainly as a last resort as
there are faster ways to attempt it such as wvdialconf to detect
modems, looking at very early boot-time messages, or using pnpdump
--dumpregs. To try to detect the physical hardware use for
example :
setserial /dev/ttyS2 -v
autoconfig
If the resulting message shows a uart type
such as 16550A, then you're OK. If instead it shows "unknown"
for the uart type, then there is supposedly no serial port at all at
that I/O address. Some cheap serial ports don't identify themselves
correctly so if you see "unknown" you still might have a serial
port there.
Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into a
configuration file such as /etc/serial.conf or
/var/lib/setserial/autoserial.conf. This will be used next
time you start Linux.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not normally permitted for the ISA
bus but it sometimes happens anyway. Probing detects one serial port
when actually there are two. However if they have different IRQs,
then the probe for IRQs may show IRQ = 0. For me, it only did this if
I first used setserial to give the IRQ a fictitious value.
While setserial may run via an initialization script,
something akin to setserial also runs earlier when the serial
module is loaded (or when the kernel starts the built-in serial driver
if it was compiled into the kernel). Thus when you watch the start-up
messages on the screen it may look like it ran twice, and in fact it
has.
But the IRQs shown may be wrong since it doesn't probe for IRQs. The second report of the same is the result of a script such as /etc/init.d/setserial. It usually does no probing and thus could be wrong about how the hardware is actually set. It only shows configuration data that got saved in a configuration files. The old method, prior to setserial 2.15, was to manually write such data directly into the script.
When the kernel loads the serial module (or if the "module equivalent"
is built into the kernel) then all supported PnP ports are detected.
For legacy (non-PnP) ports, only ttyS{0-3} are auto-detected
and the driver is set to use only IRQs 4 and 3 (regardless of what
IRQs are actually set in the hardware). No probing is done for IRQs
but it's possible to do this manually. You see this as a boot-time
message just as if setserial had been run.
For legacy ports, to correct possible errors in IRQs (or for other
reasons) there is likely a script file somewhere that runs
setserial again. Unfortunately, if this file has some IRQs
wrong, the kernel will still have incorrect info about the IRQs. This
file is usually part of the initialization done at boot-time and
whether it runs or not depends on how you (and/or your distribution)
have set up the running to these initialization scripts. It also
depends on the runlevel.
Before modifying a configuration file, you can test out a "proposed"
setserial command by just typing it on the command line. In some
cases the results of this use of setserial will automatically get
saved in /etc/serial.conf when you shutdown. So if it worked OK (and
solved your problem) then there's no need to modify any configuration
file. See
Configuration method using /etc/serial.conf, etc..
This is how it was done prior to setserial 2.15 (1999)
The objective was to modify (or create) a script file in the /etc
tree that runs setserial at boot-time. Most distributions provided
such a file (but it may not have initially resided in the /etc tree).
So prior to version 2.15 (1999) it was simpler. All you did was edit a script. There was no /etc/serial.conf file (or the like) to configure setserial. Thus you needed to find the file that runs "setserial" at boot time and edit it. If it didn't exist, you needed to create one (or place the commands in a file that ran early at boot-time). If such a file was currently being used it's likely was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it in /usr/doc/setserial/ but you need to move it to the /etc tree before using it.
The script /etc/rc.d/rc.serial was commonly used in the past.
The Debian distribution used /etc/rc.boot/0setserial.
Another file once used was /etc/rc.d/rc.local but it's may
not have run early enough. It's was reported that other processes may
try to open the serial port before rc.local ran resulting in serial
communication failure. Later on it's most likely was found in
/etc/init.d/ but wasn't normally intended to be edited.
If such a file was supplied, it likely contained a number of
commented-out examples. By uncommenting some of these and/or
modifying them, you could set things up correctly. It was important
use a valid path for setserial, and a valid
device name. You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this was a lot faster than doing repeated reboots to get
it right.
For versions >= 2.15 (provided your distribution implemented the change, Redhat didn't) it may be more tricky to do since the file that runs setserial on startup, /etc/init.d/setserial or the like was not intended to be edited by the user. See Configuration method using /etc/serial.conf, etc..
An example line in such a script was"
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
or, if you wanted setserial to automatically determine the uart and the IRQ for ttyS3 you would have used something like this:
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
This was done for every serial port you wanted to auto configure, using a device name that really does exist on your machine. In some cases it didn't work right due to the hardware.
Prior to setserial version 2.15 (1999), the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See
Edit a script (before version 2.15). Today the script and configuration file are two different
files instead of one. This shell-script is not edited but gets its
data from a configuration file such as /etc/serial.conf.
Furthermore you may not even need to edit serial.conf because using the "setserial" command on the command line may automatically cause serial.conf to be edited appropriately. This was done so that you don't need to edit any file in order to set up (or change) what setserial does each time that Linux is booted.
What often happens is this: When you shut down your PC the script
that ran "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do: It uses
"setserial" to find out what the current state of "setserial" is, and
it puts that info into the serial configuration file such as
serial.conf. Thus when you run "setserial" to change
the serial.conf file, it doesn't get changed immediately but only when
and if you shut down normally.
Now you can perhaps guess what problems might occur. Suppose you don't shut down normally (someone turns the power off, etc.) and the changes don't get saved. Suppose you experiment with "setserial" and forget to run it a final time to restore the original state (or make a mistake in restoring the original state). Then your "experimental" settings are saved. There's an option to avoid this in Debian known as "AUTOSAVE-ONCE" which will be discussed later on.
If you manually edit serial.conf, then your editing is destroyed when you shut down because it gets changed back to the state of setserial at shutdown. There is a way to disable the changing of serial.conf at shutdown and that is to remove "###AUTOSAVE###" or the like from first line of serial.conf. In the Debian distribution, the removal of "###AUTOSAVE###" from the first line was once automatically done after the first time you shutdown just after installation. To retain this effect the "AUTOSAVE-ONCE" option was created which only saves the first time the system is shut down.
The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now /etc/init.d/setserial (Debian) or /etc/init.d/serial (Redhat), or etc., but it should not normally be edited. For 2.15, Redhat 6.0 just had a file /usr/doc/setserial-2.15/rc.serial which you have to move to /etc/init.d/ if you want setserial to run at boot-time.
To disable a port, use setserial to set it to "uart none". This
will not be saved. The format of /etc/serial.conf appears to be just
like that of the parameters placed after "setserial" on the command
line with one line for each port. If you don't use autosave, you may
edit /etc/serial.conf manually.
BUG: As of July 1999 there is a bug/problem in Debian since with ###AUTOSAVE### only the setserial parameters displayed by "setserial -Gg /dev/ttyS*" get saved but the other parameters don't get saved. Use the -a flag to "setserial" to see all parameters. This will only affect a small minority of users since the defaults for the parameters not saved are usually OK for most situations. It's been reported as a bug and may be fixed by now.
In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
normally happens when you shutdown: Run the shell-script
/etc/init.d/{set}serial stop. The "stop" command will save
the current configuration but the serial ports still keep working OK.
In some cases you may wind up with both the old and new configuration methods installed but hopefully only one of them runs at boot-time. Debian labeled obsolete files with "...pre-2.15".
By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and ttyS3 share IRQ 3. But actually sharing serial interrupts (using them in running programs) is not permitted unless you: 1. have kernel 2.2 or better, and 2. you've complied in support for this, and 3. your serial hardware supports it. See
Interrupt sharing and Kernels 2.2+
If you only have two serial ports, ttyS0 and ttyS1, you're still OK since IRQ sharing conflicts don't exist for non-existent devices.
If you add a legacy internal modem (without plug-and-play) and retain ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set it both on your serial port (or modem card) and then use setserial to assign it to your device driver. If IRQ 5 is not being used for a sound card, this may be one you can use for a modem. To set the IRQ in hardware you may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP. To help you determine which spare IRQ's you might have, type "man setserial" and search for say: "IRQ 11".
If you have a Laptop, read PCMCIA-HOWTO for info on the serial configuration. For serial ports on the motherboard, setserial is used just like it is for a desktop. But for PCMCIA cards (such as a modem) it's a different story. The configuring of the PCMCIA system should automatically run setserial so you shouldn't need to run it. If you do run it (by a script file or by /etc/serial.conf) it might be different and cause trouble. The autosave feature for serial.conf shouldn't save anything for PCMCIA cards (but Debian did until 2.15-7). Of course, it's always OK to use setserial to find out how the driver is configured for PCMCIA cards.
stty does much of the configuration of the serial port but
since application programs (and the getty program) often handle it,
you may not need to use it much. It's handy if you're having problems
or want to see how the port is set up. Try typing ``stty -a'' at your
terminal/console to see how it's now set. Also try typing it without
the -a (all) for a short listing which shows how it's set different
than normal. Don't try to learn all the setting unless you want to
become a serial guru. Most of the defaults should work OK and some of
the settings are needed only for certain obsolete dumb terminals made
in the 1970's.
stty is documented in the man pages with a more detailed account
in the info pages. Type "man stty" or "info stty".
Whereas setserial only deals with actual serial ports, stty is
used both for serial ports and for virtual terminals such as the standard
Linux text interface at a PC monitor. For the PC monitor, many of the
stty settings are meaningless. Changing the baud rate, etc. doesn't
appear to actually do anything.
Here are some of the items stty configures: speed (bits/sec), parity,
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
control, break signal, end-of-line markers, change case, padding, beep
if buffer overrun?, echo what you type to the screen, allow background
tasks to write to terminal?, define special (control) characters (such
as what key to press for interrupt). See the stty man or info
page for more details. Also see the man page: termios which
covers the same options set by stty but (as of mid 1999) covers
features which the stty man page fails to mention.
With some implementations of getty (getty_ps package), the commands that one would normally give to stty are typed into a getty configuration file: /etc/gettydefs. Even without this configuration file, the getty command line may be sufficient to set things up so that you don't need stty.
One may write C programs which change the stty configuration, etc. Looking at some of the documentation for this may help one better understand the use of the stty command (and its many possible arguments). Serial-Programming-HOWTO is useful. The manual page: termios contains a description of the C-language structure (of type termios) which stores the stty configuration in computer memory. Many of the flag names in this C-structure are almost the same (and do the same thing) as the arguments to the stty command.
To set hardware flow control use "crtscts". For software flow control there are 3 settings: ixon, ixoff, and ixany.
ixany: Mainly for terminals. Hitting any key will restarts the flow after a flow-control stop. If you stop scrolling with the "stop scroll" key (or the like) then hitting any key will resume scrolling. It's seldom needed since hitting the "scroll lock" key again will do the same thing.
ixon: Enables the port to listen for Xoff and to stop transmitting when it gets an Xoff. Likewise, it will resume transmitting if it gets an Xon.
ixoff: enables the port to send the Xoff signal out the transmit line when its buffers in main memory are nearly full. It protects the device where the port is located from being overrun.
For a slow dumb terminal (or other slow device) connected to a fast PC, it's unlikely the the PC's port will be overrun. So you seldom actually need to enable ixoff. But it's often enabled "just in case".
Using stty to configure the terminal that you are currently
using is easy. Doing it for a different (foreign) terminal or serial
port may be impossible. For example, let's say you are at the PC monitor
(tty1) and want to use stty to deal with the serial port ttyS2.
Prior to about 2000 you needed to use the redirection operator "<".
After 2000 (provided your version of setserial is >= 1.17 and stty >=
2.0) there is a better method using the -F option. This will work
when the old redirection method fails. Even with the latest versions
be warned that if there is a terminal on ttyS2 and a shell is running
on that terminal, then what you see will likely be deceptive and
trying to set it will not work. See
Two interfaces at a terminal to understand it.
The new method is ``stty -F /dev/ttyS2 ...'' (or --file instead of F). If ... is -a it displays all the stty settings. The old redirection method (which still works in later versions) is to type ``stty ... </dev/ttyS2''. If the new method works but the old one hangs, it implies that the port is hung due to a modem control line not being asserted. Thus the old method is still useful for troubleshooting. See the following subsection for details.
Here's a problem with the old redirection operator (which doesn't happen if you use the newer -F option instead). Sometimes when trying to use stty, the command hangs and nothing happens (you don't get a prompt for a next command even after hitting <return>). This is likely due to the port being stuck because it's waiting for one of the modem control lines to be asserted. For example, unless you've set "clocal" to ignore modem control lines, then if no CD signal is asserted the port will not open and stty will not work for it (unless you use the newer -F option). A similar situation seems to exist for hardware flow control. If the cable for the port doesn't even have a conductor for the pin that needs to be asserted then there is no easy way to stop the hang.
One way to try to get out of the above hang is to use the newer -F option and set "clocal" and/or "crtscts" as needed. If you don't have the -F option then you may try to run some program (such as minicom) on the port that will force it to operate even if the control lines say not to. Then hopefully this program might set the port so it doesn't need the control signal in the future in order to open: clocal or -crtscts. To use "minicom" to do this you likely will have to reconfigure minicom and then exit it and restart it. Instead of all this bother, it may be simpler to just reboot the PC.
The old redirection method makes ttyS2 the standard input to stty. This gives the stty program a link to the "file" ttyS2 so that it may "read" it. But instead of reading the bytes sent to ttyS2 as one might expect, it uses the link to find the configuration settings of the port so that it may read or change them. Some people tried to use ``stty ... > /dev/ttyS2'' to set the terminal. This will not do it. Instead, it takes the message normal displayed by the stty command for the terminal you are on (say tty1) and sends this message to ttyS2. But it doesn't change any settings for ttyS2.
When using a shell (such as bash) with command-line-editing enabled there are two different terminal interfaces (what you see when you type stty -a). When you type in modern shells at the command line you have a temporary "raw" interface (or raw mode) where each character is read by the command-line-editor as you type it. Once you hit the <return> key, the command-line-editor is exited and the terminal interface is changed to the nominal "cooked" interface (cooked mode) for the terminal. This cooked mode lasts until the next prompt is sent to the terminal (which is only a small fraction of a second). Note that one never gets to type anything to this cooked mode but what was typed in raw mode gets executed while in cooked mode.
When a prompt is sent to the terminal, the terminal goes from "cooked" to "raw" mode (just like it does when you start an editor since you are starting the command-line editor). The settings for the "raw" mode are based only on the basic settings taken from the "cooked" mode. Raw mode keeps these setting but changes several other settings in order to change the mode to "raw". It is not at all based on the settings used in the previous "raw" mode. Thus if one uses stty to change settings for the raw mode, such settings will be permanently lost as soon as one hits the <return> key at the terminal that has supposedly been "set".
Now when one types stty to look at the terminal interface, one may either get a view of the cooked mode or the raw mode. You need to figure out which one you're looking at. It you use stty from another (foreign) terminal then you will see the raw mode settings. Any changes made will only be made to the raw mode and will be lost when someone presses <return> at the terminal you tried to "set". But if you type a stty command at your terminal (without the -F option or redirection) and then hit <return> it's a different story. The <return> puts the terminal in cooked mode. Your changes are saved and will still be there when the terminal goes back into raw mode (unless of course it's a setting not allowed in raw mode).
This situation can create problems. For example, suppose you corrupt your terminal interface. To restore it you go to another terminal and "stty -F dev/ttyS1 sane" (or the like). It will not work! Of course you can try to type "stty sane ..." at the terminal that is corrupted but you can't see what you typed. All the above not only applies to dumb terminals but to virtual terminals used on a PC Monitor as well as to the terminal windows in X. In other words, it applies to almost everyone who uses Linux.
Luckily, when you start up Linux, any file that runs stty at boot-time will likely deal with a terminal (or serial port with no terminal) that has no shell running on it so there's no problem for this special case.
Should you need to have stty set up the serial interface each
time the computer starts up then you need to put the stty command
in a file that will be executed each time the computer is started up
(Linux boots). It should be run before the serial port is used
(including running getty on the port). There are many possible places
to put it. If it gets put in more than one place and you only know
about (or remember) one of those places, then a conflict is likely.
So make sure to document what you do.
One place to put it would be in the same file that runs setserial when the system is booted. The location is distribution and version dependent. It would seem best to put it after the setserial command so that the low level stuff is done first. If you have directories in the /etc tree where every file in them is executed at boot-time (System V Init) then you could create a file named "stty" for this purpose.
isapnp is a program to configure Plug-and-Play (PnP) devices
on the ISA bus including internal modems. It comes in a package
called "isapnptools" and includes another program, "pnpdump" which
finds all your ISA PnP devices and shows you options for configuring
them in a format which may be added to the PnP configuration file:
/etc/isapnp.conf. The isapnp command may be put into a startup file
so that it runs each time you start the computer and thus will
configure ISA PnP devices. It is able to do this even if your BIOS
doesn't support PnP. See Plug-and-Play-HOWTO.
It's "serial line attach". It puts the serial line into a networking mode. You can thus network two computers together via a serial line using, for example, the slip protocol. But for the ppp protocol, you need to start pppd on the serial line.