Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions for ARP. Let’s see what does ARP stand for. ARP is the Address Resolution Protocol and it is used by a networked machine to resolve the hardware location/address of another machine on the same local network. Machines on the Internet are generally known by their names which resolve to IP addresses. This is how a machine on the Shafkat.com network is able to communicate with another machine which is on the bar.net network. An IP address, though, cannot tell you the physical location of a machine. This is where ARP comes into the picture.

A simple example will clarify this. If a use has a network composed of several machines. Two of the machines which are on the network are Shafkat with an IP address of 10.0.0.1 and bar with an IP address of 10.0.0.2. If Shafkat wants to ping bar to see that he is alive, but alas, Shafkat has no idea where bar is. So when Shafkat decides to ping bar he will need to send out an ARP request. This ARP request is akin to Shafkat shouting out on the network “Bar (10.0.0.2)! Where are you?”
As a result of this every machine on the network will hear Shafkat shouting, but only bar (10.0.0.2) will respond. Bar will then send an ARP reply directly back to Shafkat which is akin bar saying, “Shafkat (10.0.0.1) I am here at 00:60:94:E9:08:12.” After this simple transaction that’s used to locate his friend on the network, Shafkat is able to communicate with bar until he (his arp cache) forgets where bar is (typically after 15 minutes on Unix).

Let’s see how it works. A user can view his machines current arp/neighbor cache/table like so:
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
A users machine espa041 (9.3.76.41) knows where to find espa042 (9.3.76.42) and espagate (9.3.76.1). Now let’s add another machine to the arp cache.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms

— espa043.austin.ibm.com ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
As a result of espa041 trying to contact espa043, espa043’s hardware address/location has now been added to the arp/neighbour cache. So until the entry for espa043 times out, espa041 knows where to find espa043 and has no need to send an ARP request.
Now let’s delete espa043 from our arp cache:
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale

Now espa041 has again forgotten where to find espa043 and will need to send another ARP request the next time he needs to communicate with espa043. You can also see from the above output that espagate (9.3.76.1) has been changed to the “stale” state. This means that the location shown is still valid, but it will have to be confirmed at the first transaction to that machine.

If you followed advice and guidance as provided in this tutorial guide then you would have learnt about ARP.

Welcome to the tutorial guide. The guide will provide a user with guidance about routing policy database. If a user has a large router then he/she will be able to cater for the needs of different people, who should be served differently. The routing policy database allows a user to do this by having multiple sets of routing tables.

If a user is interested in using this feature then he/she needs to ensure that his/her kernel is compiled with the “IP: advanced router” and “IP: policy routing” features.
When the kernel needs to make a routing decision, it finds out which table needs to be consulted. By default, there are three tables. The old ‘route’ tool modifies the main and local tables, as does the ip tool (by default).
The default rules:
[ahu@home ahu]$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

This lists the priority of all rules. A user can see that all rules apply to all packets (’from all’) and also the ‘main’ table before, it is output by ip route ls, but the ‘local’ and ‘default’ table are new.
A user can generate rules which point to different tables which allow a user to override system wide routing rules.

An example will help a user to understand more about this. If a user has 3 cable modems, connected to a Linux NAT (’masquerading’) router and people living in the accommodation want to pay less to use certain services on the internet such as yahoo mail they will be then using the low-end cable modem.
Please note that the fast cable modem is known as 212.64.94.251 and is a PPP link to 212.64.94.1. The slow cable modem is known by various IP addresses, 212.64.78.148 in this example and is a link to 195.96.98.253.
The local table:
[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 10.0.0.1 dev eth0 proto kernel scope host src 10.0.0.1
broadcast 10.0.0.0 dev eth0 proto kernel scope link src 10.0.0.1
local 212.64.94.251 dev ppp0 proto kernel scope host src 212.64.94.251
broadcast 10.255.255.255 dev eth0 proto kernel scope link src 10.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 212.64.78.148 dev ppp2 proto kernel scope host src 212.64.78.148
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

The main table can be viewed as:
[ahu@home ahu]$ ip route list table main
195.96.98.253 dev ppp2 proto kernel scope link src 212.64.78.148
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0

A user can generate a rule, let’s call it ‘Shafkat’ for the house mate. Although a user can work with pure numbers, it’s simple and easy if a user adds the tables to /etc/iproute2/rt_tables.
# echo 200 Shafkat >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table Shafkat
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup Shafkat
32766: from all lookup main
32767: from all lookup default
A user can now generate Shafkat’s table, and flush the route cache:
# ip route add default via 195.96.98.253 dev ppp2 table Shafkat
# ip route flush cache

Split access

Please note that a user can set some symbolic names such as $IF1, $IF2, $IP1, etc. If we say that $IF1 is the name of the first interface and $IF2 the name of the second. A user can then use $IP1 as an IP address associated with $IF1 and $IP2 the IP address associated with $IF2. Now a user can then let $P1 be the IP address of the gateway at Provider 1, and $P2 the IP address of the gateway at provider 2. Finally, let $P1_NET be the IP network $P1 is in, and $P2_NET the IP network $P2 is in.
This will result in two additional routing tables, say T1 and T2. These are added in /etc/iproute2/rt_tables. Now a user can set up routing in these tables as follows:
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

A user can just build a route to the gateway and build a default route via that gateway, as a user would do in the case of a single upstream provider, but put the routes in a separate table per provider.
Now a user can set up the main routing table. It is good to know that that the src arguments ensure the right outgoing IP address is chosen.
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

A users preference for default route is:
ip route add default via $P1

After this, a user can set up the routing rules. These actually choose what routing table to route with. Here a user has to ensure that in order to make sure that he or she routes out a given interface if a user already has the corresponding source address:
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

Load balancing
If a user has already setup split access then instead of choosing one of the two providers as a users’ default route. Please set up the default route to be a multipath route. In the default kernel this will balance routes over the two providers. It is done as follows.
ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1

This will balance the routes over both providers. Please note that balancing will not be perfect, as it is route based, and routes are cached. This means that routes to often-used sites will always be over the same provider.
If you followed advise and guidance as provided in this tutorial guide then you would have learnt about routing policy database.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on GRE and tunnels. Please note that there are 3 kinds of tunnels in Linux. They are
IP in IP tunneling,
GRE tunneling and
tunnels that live outside the kernel such as PPTP.

Please note that the Tunnels can be used to do interesting things, but they can also affect things if they go wrong. A reason for the tunnels to go wrong is usually when a user doesn’t configure the tunnels in a right manner. Tunnelling can increase the overhead, because it needs an extra set of IP headers. Typically this is 20 bytes per packet, so if the normal packet size (MTU) on a network is 1500 bytes, a packet that is sent through a tunnel can only be 1480 bytes big. It is recommended that a user should read up on IP packet fragmentation/reassembly when he or she plans to connect large networks with tunnels..
IP in IP tunneling
IP in IP tunnelling requires 2 kernel modules, ipip.o and new_tunnel.o. If a user has three networks Let’s say you have 3 networks: Internal networks A and B, and intermediate network C
For a network A, we hase:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1
The router has address 172.16.17.18 on network C.
and network B:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1
The router has address 172.19.20.21 on network C.
As far as network C is concerned, we assume that it will pass any packet sent from A to B and vice versa.
A user needs to ensure that the modules are installed:
insmod ipip.o
insmod new_tunnel.o
Then, on the router of network A, a user can carry out following:
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
And on the router of network B:
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0
If a user has finished with the tunnel:
ifconfig tunl0 down
Please note that a user can not forward broadcast or IPv6 traffic through an IP-in-IP tunnel. A user can connect 2 IPv4 networks that and this code is compatible all the way back to 1.3 kernels. Please note that the Linux IP-in-IP tunneling doesn’t work with other Operating Systems or routers,

GRE tunneling
A user can transport multicast traffic and IPv6 through a GRE tunnel. Please note that a user will need the ip_gre.o module in Linux.
IPv4 Tunneling
If a user has 3 networks: Internal networks A and B, and intermediate network C.
Network A looks like this:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1
The router has address 172.16.17.18 on network C. A user cancall this network neta

Network B looks like this:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1

The router has address 172.19.20.21 on network C. A user can call this network netb
As far as network C is concerned, we assume that it will pass any packet sent from A to B and vice versa. How and why, we do not care.
On the router of network A, a user can go through the following:
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
In line 1, a user added a tunnel device, and called it netb. Also, the GRE protocol (mode gre) is used, the remote address is 172.19.20.21, tunneling packets should originate from 172.16.17.18 and that the TTL field of the packet is set to 255 (ttl 255).
Please note that the second line enables the device.
In the third line, a user gave the newly born interface netb the address 10.0.1.1. This is ok if a user is planning for small networks, but if a user is looking for mining expedition which means lots of tunnels that a user should consider using another IP range for tunneling interfaces.
In the fourth line a user can set the route for network B. There is a different notation for the netmask and if a user is not familiar with this then he/she can write out the netmask in binary form, and a user has to count all the ones. If a user finds this complicate then he/she should remember that 255.0.0.0 is /8, 255.255.0.0 is /16 and 255.255.255.0 is /24. Oh, and 255.255.254.0 is /23, in case you were wondering.
Let’s have a look at the router of network B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta
And when you want to remove the tunnel on router A:
ip link set netb down
ip tunnel del netb

A user can replace netb with neta for router B.

If you followed advise and guidance as provided in the tutorial guide then you would have learnt about GRE and other tunnels.

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance about file system drivers.
minix: Minix filesystem driver
An example is provided below:
modprobe minix
There are no module parameters.
ext: “Extended” filesystem driver
An example is provided below:
modprobe ext
There are no module parameters.
ext2: “Second extended” filessystem driver
An example is provided below:
modprobe ext2
There are no module parameters.
xiafs: xiafs filesystem driver
An example is provided below:
modprobe xiafs
There are no module parameters.
fat: DOS FAT filesystem functions
This module provides services for use by the MSDOS and VFAT filesystem drivers.
An example is provided below:
modprobe fat
There are no module parameters.
msdos: MSDOS filesystem driver
An example is provided below:
modprobe msdos
There are no module parameters.
This module depends on the module fat.
vfat: VFAT (Windows-95) filesystem driver
An example is provided below:
modprobe vfat
There are no module parameters.

umsdos: UMSDOS filesystem driver
This is a driver for the UMSDOS filesystem type, which is a unix style filesystem built on top of an MSDOS FAT filesystem.
An example is provided below:
modprobe vfat
There are no module parameters.
This module depends on the fat and msdos modules.
nfs: NFS filesystem driver
An example is provided below:
modprobe nfs
There are no module parameters.
smbfs: SMB filesystem driver
SMBFS is a filesystem type which has an SMB protocol interface. This is the protocol Windows for Workgroups, Windows NT or Lan Manager use to talk to each other.
An example is provided below:
modprobe smbfs
There are no module parameters
ncpfs: NCP (Netware) filesystem driver
NCPFS is a filesystem type which has an NCP protocol interface, designed by the Novell Corporation for their NetWare product. NCP is functionally similar to the NFS used in the TCP/IP community. If you would like to mount a Netware filesystem, then you need a special mount program, which can be found in the ncpfs package.
An example is provided below:
modprobe ncpfs
There are no module parameters.
This module depends on module ipx.
isofs: ISO 9660 (CDROM) filesystem driver
An example is provided below:
modprobe isofs
There are no module parameters.
hpfs: OS/2 HPFS filesystem driver
This filesystem driver for OS/2’s HPFS filesystem provides only read-only access.
An example is provided below:
modprobe hpfs
There are no module parameters.
sysv: System V and Coherent filesystem driver
Please note that this is the implementation of the SystemV/Coherent filesystem type for Linux.
It implements all of
• Xenix FS
• SystemV/386 FS
• Coherent FS

An example is provided below:
modprobe sysv
There are no module parameters.
affs: Amiga FFS filesystem driver
An example is provided below:
modprobe affs
There are no module parameters.
ufs: UFS filesystem driver
This filesystem driver provides only read-only access.
An example is provided below:
modprobe ufs
There are no module parameters.
If you followed advise and guidance as provided in this tutorial guide then you would have learnt about the file system drivers.

Welcome to the tutorial guide. The tutorial will provide advise and guidance on CDROM device drivers.
aztcd: Aztech/Orchid/Okano/Wearnes/TXC/CDROM driver
This is a driver for the Aztech, Orchid, Okano, Wearnes, TXC, and CDROM devices An example is provided below:

modprobe aztcd aztcd=0×340
Parameters:
aztcd
address of base I/O port
gscd: Goldstar R420 CDROM driver
This is a driver for the Goldstar R420 CDROM drive, which does not use either an ATA or SCSI interface.
An example of this is provided below:
modprobe gscd gscd=0×340
Parameters:
gscd
address of base I/O port. Default is 0×340, which will work for most applications. You select the address of the drive with the PN801-1 through PN801-4 jumpers on the Goldstar Interface Card. Appropriate settings are: 0×300, 0×310, 0×320, 0×330, 0×340, 0×350, 0×360, 0×370, 0×380, 0×390, 0×3A0, 0×3B0, 0×3C0, 0×3D0, 0×3E0, and 0×3F0.
sbpcd: Sound Blaster CDROM driver
This is a driver for the Matsushita, Panasonic, Creative, Longshine, and TEAC CDROM drives that don’t attach via ATA or SCSI.
An example is provided below:
modprobe sbpcd sbpcd=0×340
Parameters:
sbpcd
address of base I/O port

mcd: Mitsumi CDROM driver
This is a driver for Mitsumi CDROM drives that don’t attach via ATA or SCSI. It does not handle XA or multisession.
An example is provided below:
modprobe mcd mcd=0×300,11,0×304,5
Parameters:
mcd
This is a comma separated list of i/o base addresses and IRQs, in pairs.
mcdx: Mitsumi XA/MultiSession driver
Please note that this driver is like mcd, only it has XA and multisession functions.
An example is provided below:
modprobe mcdx mcdx=0×300,11,0×304,5
optcd: Optics Storage DOLPHIN 8000AT CDROM driver
This is the driver for the so-called “dolphin” CDROM drive form Optics Storage, with the 34-pin Sony-compatible interface. For the ATA-compatible Optics Storage 8001 drive, you will want the ATAPI CDROM driver. The driver also seems to work with the Lasermate CR328A.
An example is provided below:
modprobe optcd optcd=0×340
Parameters:
optcd
address of base I/O port
cm206: Philips/LMS CM206 CDROM driver
Please that this is the driver for the Philips/LMS cm206 CDROM drive in combination with the cm260 host adapter card.
An example is provided below:
modprobe cm206 cm206=0×300,11
Parameters:
cm206
The address of the base I/O port the driver is to drive and the IRQ the driver is to service, separated by a comma.
sjcd: Sanyo CDR-H94A CDROM driver
An example is provided below:
modprobe sjcd sjcd_base=0×340
Parameters:
sjcd_base
address of the base I/O port the driver is to drive. Default is 0×340.
The driver uses no IRQ and no DMA channel.
isp16: ISP16/MAD16/Mozart soft configurable cdrom driver
This is a driver for the ISP16 or MAD16 or Mozart soft configurable cdrom interface.
An example is provided below:
modprobe isp16 isp16_cdrom_base=0×340 isp16_cdrom_irq=3
isp16_cdrom_dma=0 isp16_cdrom_type=Sanyo
Parameters:
isp16_cdrom_base
address of base I/O port the driver is to drive. Valid values are 0×340, 0×320, 0×330, and 0×360.
isp16_cdrom_irq
IRQ the driver is to service. Valid values are 0, 3, 5, 7, 9, 10, and 11.
isp16_cdrom_dma
DMA channel the driver is to use with the device. Valid values are 0, 3, 5, 6, and 7.
isp16_cdrom_type
Type of device being driven. Valid values are noisp16, Sanyo, Panasonic, Sony and Mitsumi. Please note that these values are case sensitive.

cdu31a: Sony CDU31A/CDU33A CDROM driver
An example is provided below:
modprobe cdu31a cdu31a_port=0×340 cdu31a_irq=5
Parameters:
cdu31a_port
address of base I/O port the driver is to drive. This parameter is mandatory.
cdu31a_irq
IRQ the driver is to service. If you don’t specify this, the driver does not use interrupts.

sonycd535: Sony CDU535 CDROM driver
An example is provided below:
modprobe sonycd535 sonycd535=0×340
Parameters:
sonycd535
address of the base I/O port the driver is to drive.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about CDROM device drivers.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on adaptor driver.

de600: D-Link DE600 pocket adapter driver
This is a driver for the D-Link DE600 pocket Ethernet adapter.
An example is provided below:
modprobe de600 de600_debug=0
Parameters:
de600_debug
Please note that this driver expects the adapter to be at port 0×378 and generate IRQ 7. This is the same as the DOS lpt1 device. These are compile time options.
de620: D-Link DE620 pocket adapter driver
This is a driver for the D-Link DE620 pocket Ethernet adapter.
An example is provided below:
modprobe de620 bnc=0 utp=0 io=0×378 irq=7
Parameters:
bnc
1
Network is 10Base2
0
Network is not 10Base2
utp
1
Network is 10BaseT
0
Network is not 10BaseT
io
I/O port address of port driver is to drive. Default is 0×378.
irq
IRQ driver is to service. Default is 7.
You can’t specify both bnc=1 and utp=1.

ibmtr: Tropic chipset based token ring adapter driver
An example is provided below:
modprobe ibmtr io=0xa20 irq=5
Parameters:
io
I/O port address of port driver is to drive. Default is 0xa20.
irq
IRQ driver is to service. By default, the driver determines the IRQ by autoIRQ probing.
arcnet: ARCnet driver

An example is provided below:
modprobe arcnet io=0×300 irq=2 shmem=0xd0000 device=arc1
Parameters:
io
I/O port address of port driver is to drive. If you don’t specify this, the driver probes addresses 0×300, 0×2E0, 0×2F0, 0×2D0, 0×200, 0×210, 0×220, 0×230, 0×240, 0×250, 0×260, 0×270, 0×280, 0×290, 0×2A0, 0×2B0, 0×2C0, 0×310, 0×320, 0×330, 0×340, 0×350, 0×360, 0×370, 0×380, 0×390, 0×3A0, 0×3E0, and 0×3F0.
irq
IRQ driver is to service. By default, the driver determines the IRQ by autoIRQ probing.
device
device name.

isdn: basic ISDN functions
This provides ISDN functions used by ISDN adapter drivers.
Setting up ISDN networking is a complicated task.
An example of this is provided below::
modprobe isdn
There are no module parameters.
This module depends on module slhc.
icn: ICN 2B and 4B driver
This is a driver for the ICN 2B and ICN 4B ISDN adapters.
An example is provided below:
modprobe icn portbase=0×320 membase=0xd0000 icn_id=idstring icn_id2=idstring2
Parameters:
portbase
Address of the base I/O port on the adapter. Defaults is 0×320.
membase
Address of shared memory. Default is 0xd0000.
icn_id
idstring for the first adapter. Must start with a character! This parameter is required.
icn_id2
idstring for the second adapter. Must start with a character! This parameter is required with the double card.
This module depends on module isdn.
pcbit: PCBIT-D driver
This is a driver for the PCBIT-D ISDN adapter driver.
An example is provided below:
modprobe pcbit mem=0xd0000 irq=5
Parameters:
mem
Shared memory address. Default is 0xd0000
irq
IRQ the driver is to service. Default is 5.
This module depend on module isdn.
teles: Teles/NICCY1016PC/Creatix driver
This is a driver for the Teles/NICCY1016PC/Creatix ISDN adapter. It can drive up to 16 cards.
An example is provided below:
modprobe teles io=0xd0000,15,0xd80,2 teles_id=idstring
Parameters:
io
This is a whole collection of parameters in one. It’s syntax is io=card1options [,card2options ,…] where card1options is a set of options for the first card, etc.
The syntax of card1options, etc. is sharedmem, irq, portbase, dprotocol
sharedmem
Address of shared memory. Default 0xd0000
irq
IRQ driver is to service.
portbase
Address of base I/O port.
dprotocol
D-channel protocol of the card
1
1TR6
2
EDSS1. This is the default.
teles_id
Driver ID for accessing with utilities and identification when using a line monitor. Value must start with a character! Default: none.
The driver determines the type of card from the port, irq and shared memory address:
• port == 0, shared memory != 0 -> Teles S0-8
• port != 0, shared memory != 0 -> Teles S0-16.0
• port != 0, shared memory == 0 -> Teles S0-16.3
Please note that this module depends on module isdn.
If you followed advise and guidance as provided in this tutorial then you would have learnt about the adaptor drivers.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on Network device drivers.
. bsd_comp: optional BSD compressor for PPP
An example of this is:
modprobe bsd_comp
This module depends on module ppp.
slhc: SLHC compressor for PPP
This module contains routines to compress and uncompress tcp packets (for transmission over low speed serial lines). Please note that these routines are required by PPP (also ISDN-PP) and SLIP protocols, and are used by the LKMs that implement those protocols.
An example is :
modprobe slhc
There are no module parameters.
dummy: Dummy network interface driver
This is a bit-bucket device with a configurable IP address. It is most commonly used in order to make your currently inactive SLIP address seem like a real address for local programs.
However, it also functions as a sort of loopback device. You configure it for a particular IP address and any packet you send to that IP address via this interface comes back and appears as a packet received by that interface for that IP address. This is especially handy for an IP address that would normally be reflected by another interface (a PPP interface, perhaps), but that interface is down right now.

You can have multiple dummy interfaces. They are named dummy0, dummy1, etc.
An example of this is:
modprobe dummy
There are no module parameters.

eql: serial line load balancer
Please note that if you have two serial connections to some other computer (this usually requires two modems and two telephone lines) and you use PPP (a protocol for sending internet traffic over telephone lines) or SLIP (an older alternative to PPP) on them, you can make them behave like one double speed connection using this driver.
An example of this is:
modprobe eql
There are no module parameters.

dlci: frame relay DLCI driver
This implements the frame relay protocol; frame relay is a fast low-cost way to connect to a remote internet access provider or to form a private wide area network. The one physical line from your box to the local “switch” (i.e. the entry point to the frame relay network) can carry several logical point-to-point connections to other computers connected to the frame relay network. An example of this is:
modprobe dlci
There are no module parameters.

sdla: Sangoma S502A FRAD driver
This is a driver for the Sangoma S502A, S502E and S508 Frame Relay Access Devices. These are multi-protocol cards, but this driver can drive only frame relay right now.
An example of this is:
modprobe sdla
There are no module parameters.
This module depends on module dlci.

plip: PLIP network interface driver
PLIP (Parallel Line Internet Protocol) is used to create a mini network consisting of two (or, rarely, more) local machines. The parallel ports (the connectors virtually all ISA-descendant computers have that are normally used to attach printers) are connected using null printer or Turbo Laplink cables which can transmit 4 bits at a time or using special PLIP cables, to be used on bidirectional parallel ports only, which can transmit 8 bits at a time. The cables can be up to 15 meters long. This works also if one of the machines runs DOS/Windows and has some PLIP software installed, e.g. the Crynwr PLIP packet driver and winsock or NCSA’s telnet.

An example of this is:
modprobe plip io=0×378 irq=7
Parameters:
io
Port address of parallel port driver is to drive.
irq
IRQ number of IRQ driver is to service. Default is IRQ 5 for port at 0×3bc, IRQ 7 for port at 0×378, and IRQ 9 for port at 0×278.
If you don’t specify the io parameter, the driver probes addresses 0×278, 0×378, and 0×3bc.
ppp: PPP network protocol driver
PPP (Point to Point Protocol) is the most common protocol to use over a serial port (with or without a modem attached) to create an IP network link between two computers.
Please note that along with this kernel driver, you will also need the user space program pppd running.

An example of this is:
modprobe ppp
There are no module parameters.
This module depends on module slhc.

The module also accesses serial devices, which are driven by the serial module, so it depends on that module too. This dependency is not detected by depmod, so you either have to declare it manually or load serial explicitly.
SLIP network protocol driver
SLIP (Serial Line Internet Protocol) is like PPP, only older and simpler.
An example of this is:
modprobe slip slip_maxdev=1
Parameters:
slip_maxdev
Maximum number of devices the driver may use at one time. Default is 256.
This module depends on module slhc.
The module also accesses serial devices, which are driven by the serial module, so it depends on that module too. This dependency is not detected by depmod, so you either have to declare it manually or load serial explicitly.

baycom: BAYCOM AX.25 amateur radio driver
This is a driver for Baycom style simple amateur radio modems that connect to either a serial interface or a parallel interface. The driver works with the ser12 and par96 designs.
An example of this :
modprobe baycom modem=1 iobase=0×3f8 irq=4 options=1
Parameters:
major
major number the driver should use; default 60
modem
modem type of the first channel (minor 0):
1
ser12
2
par96/par97
iobase
base address of the port the driver is to drive. Common values are for ser12 0×3f8, 0×2f8, 0×3e8, 0×2e8 and for par96/par97 0×378, 0×278, 0×3bc.
irq
IRQ the driver is to service. Common values are 3 and 4 for ser12 and 7 for for par96/par97.
options
0
use hardware DCD
1
use software DCD
STRIP (Metricom starmode radio IP) driver
Metricom radios are small, battery powered, 100kbit/sec packet radio transceivers, about the size and weight of a wireless telephone. (You may also have heard them called “Metricom modems” but we avoid the term “modem” because it misleads many people into thinking that you can plug a Metricom modem into a phone line and use it as a modem.) You can use STRIP on any Linux machine with a serial port, although it is obviously most useful for people with laptop computers.
An example of this is:
modprobe strip
There are no module parameters.
wavelan: WaveLAN driver
WaveLAN card are for wireless ethernet-like networking. This driver drives AT&T GIS and NCR WaveLAN cards.
An example of this is:
modprobe wavelan io=0×390 irq=0
Parameters:
io
Address of I/O port on the card. Default is 0×390. You can set a different address on the card, but it is not recommended.
irq
IRQ the driver is to service. Default is 0. Any other value is ignored and the card still services IRQ 0.
wic: WIC Radio IP bridge driver
Please note that this is a driver for the WIC parallel port radio bridge.
An example of this is:
modprobe wic
It appears that devices wic0, wic1 and wic2 are directly related to corresponding lpN ports.
scc: Z8530 SCC kiss emulation driver
These cards are used to connect your Linux box to an amateur radio in order to communicate with other computers.
An example of this is:
modprobe scc
There are no module parameters.
8390: General NS8390 Ethernet driver core
This is driver code for the 8390 Ethernet chip on which many Ethernet adapters are based. This is not a complete interface driver; the routines in this module are used by drivers for particular Ethernet adapters, such as ne and 3c503.
An example of this is:

modprobe 8390
There are no module parameters.

ne: NE2000/NE1000 driver
This is a driver for the venerable NE2000 Ethernet adapter, its NE1000 forerunner, and all the generic Ethernet adapters that emulate this de facto standard card. This is an ISA bus card. For the PCI version, see the ne2k-pci module.
An example of this is:
modprobe ne io=0×300 irq=11
Parameters:
io
Address of I/O port on the card. This parameter is mandatory, but you may specify 0×000 to have the driver autoprobe 0×300, 0×280, 0×320, 0×340, and 0×360.
irq
IRQ the driver is to service. If you don’t specify this, the driver determines it by autoIRQ probing.
bad
The value 0xBAD means to assume the card is poorly designed in that it does not acknowledge a reset or does not have a valid 0×57,0×57 signature. If you have such a card and do not specify this option, the driver will not recognize it.
With any other value, the option has no effect.
You can repeat the options to specify additional cards. The nth occurence of an option applies to the nth card.
This module depends on module 8390.
ne2k-pci: NE2000 PCI Driver
This is a driver for the PCI version of the venerable NE2000 Ethernet adapter, and all the generic Ethernet adapters that emulate this de facto standard card.
An example of this is:
modprobe ne io=0×300 irq=11
Parameters:
debug
Level of debug messages. 0 means no messages. 1 is the default. Higher numbers mean more debugging messages.
options
The value of this option determines what options are set in the network adapter. Each bit of the value, expressed as a binary number, controls one option. The only option defined is full duplex, which is the 6th least significant bit. It is much easier to use the full_duplex option instead.
full_duplex
A “1″ value sets the adapter in full duplex mode. A “0″ value sets it in half duplex mode. If you include the full duplex flag in the flags you specify with the options parameter, the full_duplex has no effect.
You may repeat the options and full_duplex parameters once per network adapter, for up to 8 network adapter.
This driver can drive the following chipsets:
• RealTek RTL-8029
• Winbond 89C940
• Winbond W89C940F
• KTI ET32P2
• NetVin NV5000SC
• Via 86C926
• SureCom NE34
• Holtek HT80232
• Holtek HT80229
• Compex RL2000
This module depends on module 8390.
3c501: 3COM 3c501 Ethernet driver
This is a driver for 3COM’s 3c501 Ethernet adapter.
An example of this is: modprobe 3c501 io=0×280 irq=5
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service. Default is 5.
If you don’t specify an I/O port, the driver probes addresses 0×280 and 0×300.
3c503: 3COM 3c503 driver
This is a driver for 3COM’s 3c503 Ethernet adapter.
An example of this is:
modprobe 3c503 io=0×300 irq=5 xcvr=0
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service.
xcvr
Determines whether to use external tranceiver.
0
no
1
yes
If you don’t specify an I/O port, the driver probes addresses 0×300, 0×310, 0×330, 0×350, 0×250, 0×280, 0×2A0, and 0×2E0.
This module depends on module 8390.
3c505: 3COM 3c505 driver
Please note that this is a driver for 3COM’s 3c505 Ethernet adapter.
An example of this is:
modprobe 3c503 io=0×300 irq=5 xcvr=0
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service.
If you don’t specify an I/O port, the driver probes addresses 0×300, 0×280, and 0×310.
This module depends on module 8390.
3c507: 3COM 3c507 driver
This is a driver for 3COM’s 3c507 Ethernet adapter.
An example of this is:
modprobe 3c503 io=0×300 irq=5 xcvr=0
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service.
If you don’t specify an I/O port, the driver probes addresses 0×300, 0×320, 0×340, and 0×280.
This module depends on module 8390.
3c509: 3COM 3c509/3c579 driver
Please note that this is a driver for 3COM’s 3c507 and 3c579 Ethernet adapters.
Example:
modprobe 3c503 io=0×300 irq=5 xcvr=0
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service.
Module load-time probing Works reliably only on EISA, ISA ID-PROBE IS NOT RELIABLE! Bind this driver into the base kernel for now, if you need it auto-probing on an ISA-bus machine.
3c59x: 3COM 3c590 series “Vortex” driver
This is a driver for the following 3COM Ethernet adapters:
• 3c590 Vortex 10Mbps.
• 3c595 Vortex 100baseTX.
• 3c595 Vortex 100baseT4.
• 3c595 Vortex 100base-MII.
• EISA Vortex 3c597.
An example of this is:
modprobe 3c59x debug=1 options=0,,12
Parameters:
debug
A number selecting the level of debug messages.
options
This is a string of options numbers separated by commas. There is one option number for each adapter that the driver drives (for the case that you have multiple Ethernet adapters in the system of types driven by this driver). The order of the option numbers is the order of the cards assigned by the PCI BIOS.
Each number represents a binary value. In that value, the lower 3 bits is the media type:
0
10baseT
1
10Mbs AUI
2
undefined
3
10base2 (BNC)
4
100base-TX
5
100base-FX
6
MII (not yet available)
7
Use default setting
The next bit (the “8″ bit) is on for full duplex, off for half.
The next bit (the “16″ bit) is on to enable bus-master, which is for experimental use only.
Details of the device driver implementation are at the top of the source file.
wd: Western Digital/SMC WD80*3 driver
This is a driver for the Western Digital WD80*3 Ethernet adapters.
Example:
modprobe wd io=0×300 irq=5 mem=0×0D0000 mem_end=0×0D8000
Parameters:
io
Address of I/O port on the card.
irq
IRQ the driver is to service.
mem
Shared memory address
mem_end
End of shared memory (address of next byte after it).
If you don’t specify an I/O port, the driver probes 0×300, 0×280, 0×380, and 0×240.
If you don’t specify an IRQ, the driver reads it from the adapter’s EEPROM and with ancient cards that don’t have it, the driver uses autoIRQ.
The driver depends on module 8390.
smc-ultra: SMC Ultra/EtherEZ driver
This is a driver for the SMC Ultra/EtherEZ Ethernet adapters.
An example of this is:
modprobe smc-ultra io=0×200 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×200, 0×220, 0×240, 0×280, 0×300, 0×340, and 0×380.
irq
IRQ the driver is to service. Default is the value read from the adapter’s EEPROM.
This driver depends on module 8390.
smc9194: SMC 9194 driver
This is a driver for SMC’s 9000 series of Ethernet cards.
An example of this is:
modprobe smc9194 io=0×200 irq=5 ifport=0
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×200, 0×220, etc. up through 0×3E0.
irq
IRQ the driver is to service.
ifport
Type of Ethernet.
0
autodetect
1
TP
2
AUI (or 10base2)
The debug level is settable in the source code.
at1700: AT1700 driver
This is a driver for the AT1700 Ethernet adapter.
An example of this ise:
modprobe at1700 io=0×260 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×260, 0×280, 0×2A0, 0×240, 0×340, 0×320, 0×380, and 0×300.
irq
IRQ the driver is to service.
e2100: Cabletron E21xx driver
An example of this is:
modprobe e2100 io=0×300 irq=5 mem=0xd0000 xcvr=0
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×300, 0×280, 0×380, and 0×220.
irq
IRQ the card is to generate and the driver is to service. (The driver sets this value in the card).
mem
shared memory address. Default is 0xd0000.
xcvr
0
Don’t select external transceiver
1
Select external transceiver
This module depends on module 8390.
depca: DEPCA, DE10x, DE200, DE201, DE202, DE422 driver
This is a driver for the DEPCA, DE10x, DE200, DE201, DE202, and DE422 Ethernet adapters.
An example of this is:
Modprobe depca io=0×200 irq=7
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×300, and 0×200 on an ISA machine or 0×0c00 on an EISA machine.
irq
IRQ the driver is to service. Default is 7.
ewrk3: EtherWORKS 3 (DE203, DE204, DE205) driver
This is a driver for the EtherWORKS 3 (DE203, D3204, and DE205) Ethernet adapters.
An example of this is:
Modprobe ewrk3 io=0×300 irq=5
io
Address of I/O port on the card. Default is 0×300.
irq
IRQ the driver is to service. Default is 5.
On an EISA bus, this driver does EISA probing.
On an ISA bus, this driver does no autoprobing when loaded as an LKM. However, if you bind it into the base kernel, it probes addresses 0×100, 0×120, etc. up through 0×3C0 except 0×1E0 and 0×320.
eexpress: EtherExpress 16 driver
This is a driver for the EtherExpress 16 Ethernet adapter.
An example of this is:
Modprobe eexpress io=0×300 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×300, 0×270, 0×320, and 0×340. 1
irq
IRQ the driver is to service. The default is the value read from the adapter’s EEPROM.
eepro: EtherExpressPro driver
This is a driver for the EtherExpressPro Ethernet adapter.
An example of this is:
Modprobe eepro io=0×200 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×200, 0×240, 0×280, 0×2C0, 0×300, 0×320, 0×340, and 0×360.
irq
IRQ the driver is to service.
fmv18k: Fujitsu FMV-181/182/183/184 driver
This is a driver for the Fujitsu FMV-181, FMV-182, FMV-183, FMV-183, and FMV-184 Ethernet adapters.
An example of this is:
Modprobe fmv18x io=0×220 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×220, 0×240, 0×260, 0×280, 0×2a0, 0×2c0, 0×300, and 0×340.
irq
IRQ the driver is to service.
hp-plus: HP PCLAN+ (27247B and 27252A) driver
This is a driver for HP’s PCLAN+ (27247B and 27252A) Ethernet adapters.
An example of this is:
Modprobe hp-plus io=0×200 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×200, 0×240, 0×280, 0×2C0, 0×300, 0×320, and 0×340.
irq
IRQ the driver is to service. The default is the value the driver reads from the adapter’s configuration register.
This module depends on module 8390.
hp: HP PCLAN (27245, 27xxx) driver
This is a driver for HP’s PCLAN (27245 and other 27xxx series) Ethernet adapters.
An example of this is:
Modprobe hp io=0×300 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes 0×300, 0×320, 0×340, 0×280, 0×2C0, 0×200, and 0×240.
irq
IRQ the driver is to service. If you don’t specify this, the driver determines it by autoIRQ probing.
This module depends on module 8390.
hp100: HP 10/100VG PCLAN (ISA, EISA, PCI) driver
This is a driver for HP’s 10/100VG PCLAN Ethernet adapters. It works with the ISA, EISA, and PCI versions.
An example of this is:
Modprobe hp100 hp100_port=0×100
Parameters:
hp100_port
Base address of I/O ports on the card. If you don’t specify this, the driver autoprobes 0×100, 0×120, etc. up through 0×3E0 on an ISA bus. It does EISA probing on an EISA bus.
eth16i: ICL EtherTeam 16i/32 driver
This is a driver for ICL’s EtherTeam 16i (eth16i) and 32i (eth32i) Ethernet adapters.
An example of this is:
Modprobe eth16i io=0×2a0 irq=5
Parameters:
io
Address of I/O port on the card. If you don’t specify this, the adapter probes the following adddresses. For the eth16i adapter: 0×260, 0×280, 0×2A0, 0×340, 0×320, 0×380, and 0×300. For the eth32i: 0×1000, 0×2000, 0×3000, 0×4000, 0×5000, 0×6000, 0×7000, 0×8000, 0×9000, 0xA000, 0xB000, 0xC000, 0xD000, 0xE000, and 0xF000.
irq
IRQ the driver is to service. If you don’t specify this, the driver determines it by autoIRQ probing.
ni52: NI5210 driver
This is a driver for the NI5210 Ethernet adapter.
An example of this is:
Modprobe ni52 io=0×360 irq=9 memstart=0xd0000 memend=0xd4000

ac3200: Ansel Communications EISA 3200 driver
This is a driver for the Ansel Communications EISA 3200 Ethernet adapter.
An example of this :
modprobe ac3200
This module depends on module 8390.
apricot: Apricot Xen-II on board ethernet driver
An example of this is:
Modprobe apricot io=0×300 irq=10
Parameters:
io
address of base I/O port on card.
irq
IRQ that driver is to service.
de4×5: DE425, DE434, DE435, DE450, DE500 driver
This is a driver for the DE425, DE434, DE435, DE450, and DE500 Ethernet adapters.
An example of this is:

modprobe de4×5 io=0×000b irq=10 is_not_dec=0
Parameters:
io
address of base I/O port.
irq
IRQ the driver is to service.
is_not_dec
For a non-DEC card using the DEC 21040, 21041, or 21140 chip, set this to 1.
tulip: DECchip Tulip (dc21×4x) PCI driver
An example of this is:
Modprobe tulip

This is a driver for the Digi International RightSwitch SE-X EISA and PCI boards. These boards have a 4 (EISA) or 6 (PCI) port Ethernet switch and a NIC combined into a single board.
There is a tool for setting up input and output packet filters on each port, called dgrsfilt.
The management tool lets you watch the performance graphically, as well as set the SNMP agent IP and IPX addresses, IEEE Spanning Tree, and Aging time. These can also be set from the command line when the driver is loaded.
There is also a companion management tool, called xrightswitch.
An example is:
modprobe dgrs debug=1 dma=0 spantree=0 hashexpire=300 ipaddr=199,86,8,221
modprobe ipxnet=111
Parameters:
debug
Level of debugging messages to print
dma
0
Disable DMA on PCI card
1
Enable DMA on PCI card
spantree
0
Disable IEEE spanning tree
1
Enable IEEE spanning tree
hashexpire
Change address aging time, in seconds. Defaults is 300.
ipaddr
SNMP agent IP address. Value is IP address in dotted decimal notation, except with commas instead of periods.
ipxnet
SNMP agent IPX network number
If you followed this tutorial guide then you would have learnt about network device drivers.

Welcome to the tutorial guide. The tutorial guide will provide a user with advise and guidance about SCSI drivers.
Please note that Linux’s SCSI function is implemented in three layers, and there are LKMs for all of them.
In the middle is the mid-level driver or SCSI core. This consists of the scsi_mod LKM. It does all those things that are common among SCSI devices regardless of what SCSI adapter a user uses and what class of device (disk, scanner, CD-ROM drive, etc.) it is.
There is a low-level driver for each kind of SCSI adapter — typically, a different driver for each brand. For example, the low-level driver for Advansys adapters (made by the company which is now Connect.com) is named advansys.

High-level drivers present to the rest of the kernel an interface appropriate to a certain class of devices. The SCSI high-level driver for tape devices, st, for example, has ioctls to rewind. The high-level SCSI driver for CD-ROM drives, sr, does not.
Please note that a user rarely needs a high-level driver specific to a certain brand of device. At this level, there is little room for one brand to be distinguishable from another.
One SCSI high-level driver that deserves special mention is sg. This driver, called the “SCSI generic” driver, is a fairly thin layer that presents a rather raw representation of the SCSI mid-level driver to the rest of the kernel. User space programs that operate through the SCSI generic driver (because they access device special files whose major number is the one registered by sg (to wit, 21)) have a detailed understanding of SCSI protocols, whereas user space programs that operate through other SCSI high-level drivers typically don’t even know what SCSI is.

The layering order of the SCSI modules belies the way the LKMs depend upon each other and the order in which they must be loaded. A user should load the mid-level driver first and unload it last. The low-level and high-level drivers can be loaded and unloaded in any order after that, and they hook themselves into and establish dependency on the mid-level driver at both ends. If a user doesn’t have a complete set, a user will get a “device not found” error when he/she tries to access a device.
Most SCSI low-level (adapter) drivers don’t have LKM parameters; they do generally autoprobe for card settings. If a users card responds to some unconventional port address he/she must bind the driver into the base kernel and use kernel “command line” options.

Many SCSI low-level drivers have documentation in the drivers/scsi directory in the Linux source tree, in files called README.*.
15.3.1. scsi_mod: SCSI mid-level driver
Example:
modprobe scsi_mod
There are no module parameters.
15.3.2. sd_mod: SCSI high-level driver for disk devices
Example:
modprobe sd_mod
There are no module parameters.
15.3.3. st: SCSI high-level driver for tape devices
Example:
modprobe st
There are no module parameters for the LKM, but if a user binds this module into the base kernel, he/she can pass some parameters via the Linux boot parameters.

sr_mod: SCSI high-level driver for CD-ROM drives
An example of this is:
modprobe sr_mod
sg: SCSI high-level driver for generic SCSI devices
An example of this is:
modprobe sg

wd7000: SCSI low-level driver for 7000FASST
An example of this is:
modprobe wd7000
Please note that this driver atoprobes the card and requires installed BIOS.

aha152x: SCSI low-level driver for Adaptec AHA152X/2825
An example of this is:
modprobe aha152x
This driver atoprobes the card and requires installed BIOS.

aha1542: SCSI low-level driver for Adaptec AHA1542
An example of this is:
modprobe aha1542

This driver autoprobes the card at 0×330 and 0×334 only.

aha1740: SCSI low-level driver for Adaptec AHA1740 EISA
An example of this is:
modprobe aha1740
Please note that this driver autoprobes the card.
aic7xxx: SCSI low-level driver for Adaptec AHA274X/284X/294X
An example of this is:
modprobe aic7xxx
Please note that this driver autoprobes the card and BIOS must be enabled.
advansys: SCSI low-level driver for AdvanSys/Connect.com
An example of this is:
modprobe advansys asc_iopflag=1 asc_ioport=0×110,0×330 asc_dbglvl=1

Module Parameters:
asc_iopflag
1
enable port scanning
0
disable port scanning
asc_ioport
I/O port addresses to scan for Advansys SCSI adapters
asc_dbglvl
debugging level:
0
Errors only
1
High level tracing
2-N
Verbose tracing
If a user binds this driver into the base kernel, then he/she can pass parameters to it via the kernel boot parameters.
in2000: SCSI low-level driver for Always IN2000
An example of this:
modprobe in2000

Please note that this driver autoprobes the card. No BIOS is required.

BusLogic: SCSI low-level driver for BusLogic
The list of BusLogic cards this driver can drive is long. Read file drivers/scsi/README.BusLogic in the Linux source tree to get the total picture.
An example of this:
modprobe BusLogic

If a user binds this driver into the base kernel then he/she can pass parameters to it via the kernel boot parameters.

dtc: SCSI low-level driver for DTC3180/3280
An example of this is:
modprobe dtc
Please note that this driver autoprobes the card.

eata: SCSI low-level driver for EATA ISA/EISA
An example of this driver is:
modprobe eata

eata_dma: SCSI low-level driver for EATA-DMA
This driver handles DPT, NEC, AT&T, SNI, AST, Olivetti, Alphatronix, DPT Smartcache, Smartcache III and SmartRAID.
An example of this is:
modprobe eata_dma

Autoprobe works in all configurations.

eata_pio: SCSI low-level driver for EATA-PIO
This driver handles old DPT PM2001, PM2012A.
An example of this is:
modprobe eata_pio

fdomain: SCSI low-level driver for Future Domain 16xx
An example of this is:
modprobe fdomain

This driver autoprobes the card and requires installed BIOS.
NCR5380: SCSI low-level driver for NCR5380/53c400
An example of this is:
modprobe NCR5380 ncr_irq=xx ncr_addr=xx ncr_dma=xx ncr_5380=1 \
ncr_53c400=1
for a port mapped NCR5380 board:
modprobe g_NCR5380 ncr_irq=5 ncr_addr=0×350 ncr_5380=1
for a memory mapped NCR53C400 board with interrupts disabled:
modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1
Parameters:
ncr_irq
the irq the driver is to service. 255 means no or DMA interrupt. 254 to autoprobe for an IRQ line if overridden on the command line.
ncr_addr
the I/O port address or memory mapped I/O address, whichever is appropriate, that the driver is to drive
ncr_dma
the DMA channel the driver is to use
ncr_5380
1 = set up for a NCR5380 board
ncr_53c400
1 = set up for a NCR53C400 board
If a user binds this driver into the base kernel, then he/she can pass parameters to it via the kernel boot parameters.

NCR53c406a: SCSI low-level driver for NCR53c406a
An example of this is:
modprobe NCR53c406a
There are no module parameters for the LKM, but if a user binds this module into the base kernel.

53c7,8xx.o: SCSI low-level driver for NCR53c7,8xx
An example of this is:
modprobe 53c7,8xx

This driver autoprobes the card and requires installed BIOS.

ncr53c8xx: SCSI low-level driver for PCI-SCS NCR538xx family
An example of this is:
modprobe ncr53c8xx
There are no module parameters.
ppa: low-level SCSI driver for IOMEGA parallel port ZIP drive
An example of this driver is:
modprobe ppa ppa_base=0×378 ppa_nybble=1
Parameters:
ppa_base
Base address of the PPA’s I/O port. Default 0×378.
ppa_speed_high
Delay used in data transfers, in microseconds. Default is 1.
ppa_speed_low
Delay used in other operations, in microseconds. Default is 6.
ppa_nybble
1 = Use 4-bit mode. 0 = don’t. Default is 0.
pas16: SCSI low-level driver for PAS16
An example of this is:
modprobe pas16
This driver autoprobes the card. No BIOS is required.
qlogicfas: SCSI low-level driver for Qlogic FAS
An example of this is:
modprobe qlogicfas

qlogicisp: SCSI low-level driver for Qlogic ISP
An example of this is:
modprobe qlogicisp

seagate: SCSI low-level driver for Seagate, Future Domain
This driver is for Seagate ST-02 and Future Domain TMC-8xx.
An example of this is:
modprobe Seagate

This driver autoprobes for address only. The IRQ is fixed at 5. The driver requires installed BIOS.
t128: SCSI low-level driver for Trantor T128/T128F/T228
An example of this is:
modprobe t128

This driver autoprobes the card. The driver requires installed BIOS.
u14-34f: SCSI low-level driver for UltraStor 14F/34F
An example of this is:
modprobe u14-34f
This driver autoprobes the card, but not the 0×310 port. No BIOS is required.

ultrastor: low-level SCSI driver for UltraStor
An example of this is:
modprobe ultrastor

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about SCSI disk drivers.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on linear disk array device driver.

Please note that this driver lets a user combine several disk partitions into one logical block device. If a user use this, then his/her multiple devices driver will be able to use the so-called linear mode, i.e. it will combine the disk partitions by simply appending one to the other.

For example:
modprobe linear
There are no module parameters.
raid0: RAID-0 device driver
This driver lets a user combine several disk partitions into one logical block device.
If a user uses this, then his/her multiple devices driver will be able to use the so-called raid0 mode, i.e. it will combine the disk partitions into one logical device in such a fashion as to fill them up evenly, one chunk here and one chunk there. This will increase the throughput rate if the partitions reside on distinct disks.

For example:
modprobe raid0
rd: ramdisk device driver
A ramdisk is a block device whose storage is composed of system memory (real memory; not virtual). A user can use it like a very fast disk device and also in circumstances where he/she need a device, but don’t have traditional hardware devices to play with.

A user can have his/her boot loader (e.g. lilo) create a ramdisk and load it with data (perhaps from a floppy disk). Please note that a user cannot use the LKM version of the ramdisk driver because the driver will have to be in the kernel at boot time.

A ramdisk is actually conceptually simple in Linux. Disk devices operate through memory because of the buffer cache. The only difference with a ramdisk is that a user can never actually get past the buffer cache to a real device. This is because with a ramdisk, 1) when he/she first access a particular block, Linux just assumes it is all zeroes; and 2) the device’s buffer cache blocks are never written to the device, ergo never stolen for use with other devices. This means reads and writes are always to the buffer cache and never reach the device.

There is additional information about ramdisks in the file Documentation/ramdisk.txt in the Linux source tree.
An example is provided below:
Modprobe rd
There are no module parameters that a user can supply to the LKM, but if he/she bind the module into the base kernel, there are kernel parameters a user can pass to it.

XT disk device driver
This is a very old 8 bit hard disk controllers used in the IBM XT computer. No, the existence of XT disk support does NOT mean that a user can run Linux on an IBM XT :).
For example:
modprobe xd
There are no module parameters.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about disk device driver.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on loop device driver. This information will let a user mount a filesystem that is stored in a regular file. That other file is called the backing file.

One use of this is to test an ISO 9660 filesystem before irreversibly burning it onto a CD. A user can build the filesystem in a 650 MB regular file. That file will be the input to the CD burning program, but a user should define a loopback device based on that file as backing file and then mount the filesystem right from the backing file.
It can also give a user a handy way to transmit collections of files over a network. It’s like a tar file, only a user don’t have to pack and unpack it – a user just mount the original file.

Some people use loop devices on a machine that sometimes runs Windows and sometimes runs Linux to allow them to maintain the Linux system via the Windows system: put a Linux root filesystem in a file in a FAT filesystem that Windows can access, then mount the Linux root filesystem via a loop device when Linux is running.

A user can keep the filesystem encrypted or compressed, or encoded in any arbitrary way, in the backing file. The loop device encodes (e.g. encrypts) as he/she write to it, and decodes (e.g. decrypts) as a user reads.

An encoding system is based on a “transfer function”. There are two transfer functions built into the loop module: the identify transfer function and a simple XOR encryption function. A separate kernel module can add any transfer function by calling the loop module’s exported loop_register_transfer() function.

There appear to be various modules floating around that provide transfer functions to do compression and encryption (DES, IDEA, Fish, etc.). Some of them appear to be part of current Linux kernel distributions. In addition, there appear to be various alternative loop device drivers, many of them also called loop, that have such transfer functions built in.

Please note that you do not confuse these loop devices with the “loopback device” used for network connections from the machine to itself. That isn’t actually a device at all - it’s a network interface.

A user can set up a loop device by issuing an ioctl to it to bind a file to it. The typical program to issue this ioctl is losetup. There are also options on the normal ‘mount’ command to do loop device setup under the covers, but because that confuses the logically separate operations of setting up a loop device and mounting a filesystem, for the sake of clarity you’re probably better off using losetup.
Please view this example:
modprobe loop
Module Parameters:
max_loop
Number of loop devices that will exist. Contrary to what its name suggests, the number that a user can specify is the number of loop devices that always exist. An existing device is not necessarily configured (bound to a backing file), though, so this number can be thought of as the maximum number of loop devices that you can configure.
The minor numbers for these loop devices are consecutive starting at 0.

If you followed advise and guidance as provided in this tutorial guide then you would have successfully learnt about the loop driver.