This is incorrect (the driver fondles every byte).
I believe the problem resides in the fact that timer queues
("software interrupts") are used to perform the necessary polling of the
device. The use of timer interrupts is unavoidable as the only other alternative
would result in something like 60+ layers of function calls on the kernel
stack which causes a kernel panic.
What I would like to know is there a way of allocating the time spent inside a
software interrupt to a known process?
eg:
queuecommand() - queue a SCSI command:
a) Receive request
b) record process ID
c) toss request onto timer queue
d) exit
Software interrupt:
a) Called by bh handler
b) set current process ID to recorded process ID
c) perform processing
d-1) if not complete, toss another request onto the timer queue
d-2) if complete call "done() function"
e) exit
The problem in trying to directly incorporate the software interupt routine
directly into the queuecommand() is that when the "done()" function is called
another call to queuecommand() is made (resulting in massive procedure
recursion). The software interrupt allows a breather while the calling stack
unravels.
This "missing time" does not affect the operation of the device but it certainly
makes it hard to determine device driver efficency (sec kernel time/MB
transfered).
David Campbell
PS: Please ensure that I am CC'd on any responses.
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers (documentation needed)
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers (75% complete)
Any assistance to clearing this list most welcome
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/