|
The ZIP Parallel Interface
Module Topology
It is useful to see how the zip module integrates into the kernel.
Module topology looks as follows:
Note in this diagram, that the ppa/imm module also talks directly to the interface, rather than through the module stack. Note further that applications go thru the file system to 'get at' the zip drive.
Zip drivers are loaded by ONE of the the following commands:
modprobe ppa # the old interface
modprobe imm # the NEW interface
modprobe zip # the combined interface
There are NO parameters.
modprobe takes care of the details of which underlying support modules are required should they not be already loaded.
Loading triggers and hand feeding.
Applications make requests of kernel functions.
Not all functions are 'available' in a just booted Linux OS because the kernel is modularised. It is modularised so that, if you don't have USB, then the code functions for USB are not wasting memory and never used.
The Linux kernel passes requests to modprobe when it can't find a function in it's current memory. It is up to modprobe to find that function in the list of modules that modprobe knows about (in /lib/modules).
Thus, some modules are transparently and automatically loaded simply by an application requesting some function that the kernel doesn't currently have. This mechanism works for example with printing. A print request, gets resolved by modprobe as the lp.o module.
For ZIP, and all other device drivers (ethernet), there is no trigger mechanism. The applications don't call anything unique to zip drives (or ethernet cards). So, the result is that you need to force feed these types of modules.
Caldera's approach is to provide /etc/modules/default, which contains a list of force fed drivers, loaded at boot time. Forced, because no other mechanism will trigger them.
THE modules required.
imm/ppa/zip cause the following modules to load (if not already present)
parport
parport_pc (alias parport_lowlevel)
parport_probe
imm/ppa/zip
parport_lowlevel is aliased to the machine architecture. In this case an IBM PC.
The reason why these modules are required is that the zip drive makes use of parport's detection utility. Ie the number and type of printer interface(s).
Kernel source code directories
| /usr/src/linux/drivers/~ | /usr/src/linux/include/ | |
| parport.o | misc/parport_init.c | parport.h |
| misc/parport_ieee1284.c | ||
| misc/parport_procfs.c | ||
| misc/parport_share.c | ||
| parport_pc.o | misc/parport_pc.c | parport_pc.h |
| parport_probe.o | pnp/parport_probe.c |
The generic module parport.o, contains multiple source files which are architecture agnostic. IEEE is IEEE.
parport_pc.o is the machine dependent code. Confusion for some: parport_lowlevel is the machine agnostic kernel call and hence /etc/modules.conf requires
alias parport_lowlevel parport_pc
or (eg)
alias parport_lowlevel parport_macintosh
parport_probe.o is a do nothing module, which conveniently lists what IEEE devices it can detect on the interface (via dmesg). Zip drives, among others, are NOT IEEE compliant and are not detected.
next-> the SCSI interface