Linux Step By Steps

Module Overview: Detection

The first part of the driver's responsibility is to detect the presence of a zip drive(s) on any of the possible parallel ports.

The number, and type, of parallel ports have been previously detected by the parport modules. These modules are normally initiated when the printer driver (lp.o) is loaded. If not, it will be loaded automatically by modprobe just prior to imm/ppa being called.

The imm/ppa/zip drivers do not use the parport modules for driving the interface. Their only use is in

• parport_enumerate(), which successively returns an information structure for each parallel card.

• parport_register/unregister() makes module 'in use'

• parport_claim/release() which locks / unlocks the interface for other callers.

(Printing and reading a zip drive occurs simultaneously via claim() and release(). Kernel drivers fully expect 'someone else' to be using 'their card'. Thus drivers are written to claim and release the interface on each block of data sent / received, so that the other guy can get in.)

In  zip source code, 

registration() occurs and remains active if any zip drives are found.

claim() and release() surround each 'session'. One such session is detection.

unregister() occurs, naturally enough, only when the module itself is removed (rmmod). Note that this is de-registration of the parallel interface(s), the de-registration of the zip module itslef, inititiates this process.

As a side comment, you should be able to follow this mechansim by using the insmod/lsmod/rmmod family of commands and notice the 'in use' flags preventing removal of specific dependent modules.

Function body brace.

The C code necessary to implement the above structure can be approximated as follows

detect()
{
parport_enumerate();
    parport_register_device();
        parport_claim();
            session()
        parport_release();
}

And, while the module is loaded, The driver will perform

queuecommand()
{
        parport_claim();
            session();
        parport_release();
}

Detection proper

The parport modules can only establish what the interface is capable of. Therefore, the zip driver  first attempts an ecp connection regardless of what parport thinks. If the connection fails, the parport information is used to determine if the interface, not the device, is capable of bidirectional, or simple nibble mode and the protocol string is sent again.

The actual sequence of six 0 bytes sent is covered elsewhere as the detection routine itself follows the standard handshake, connection and protocol conventions of all zip communication. All that the detection routine is interested in is if it got a response.