URL
https://opencores.org/ocsvn/or1k/or1k/trunk
Subversion Repositories or1k
[/] [or1k/] [trunk/] [uclinux/] [uClinux-2.0.x/] [Documentation/] [scsi.txt] - Rev 1775
Go to most recent revision | Compare with Previous | Blame | View Log
The scsi support in the linux kernel can be modularized in a
number of different ways depending upon the needs of the end user. To
understand your options, we should first define a few terms.
The scsi-core contains the core of scsi support. Without it
you can do nothing with any of the other scsi drivers. The scsi core
support can be a module (scsi_mod.o), or it can be build into the kernel.
If the core is a module, it must be the first scsi module loaded, and
if you unload the modules, it will have to be the last one unloaded.
The individual upper and lower level drivers can be loaded in any
order once the scsi core is present in the kernel (either compiled in
or loaded as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o),
tape driver (st.o) and scsi generics driver (sg.o) represent the upper level
drivers to support the various assorted devices which can be controlled.
You can for example load the tape driver to use the tape drive, and then
unload it once you have no further need for the driver (and release the
associated memory).
The lower level drivers are the ones that support the
individual cards that are supported for the hardware platform that you
are running under. Examples are aha1542.o to drive Adaptec 1542
cards. Rather than list the drivers which *can* be modularized, it is
easier to list the ones which cannot, since the list only contains a
few entries. The drivers which have NOT been modularized are:
NCR5380 boards of one kind or another including PAS16,
Trantor T128/128F/228,
Go to most recent revision | Compare with Previous | Blame | View Log