Consider a printer attached to a ZIP drive attached to the only parallel
port in a system. There needs to be a mechanism to allow both the lp
and ppa drivers to access that port so that one could print
a file from the ZIP drive, for instance.
The simplest solution would be to use semaphores. In some appropriate
place deep in the kernel, we could allocate a semaphore for each of the
parallel ports and fix each of the drivers to 'down' the semaphore before
accessing the port and to 'up' it when the port is back in a state
where a different driver could use it. In the ppa driver, for instance,
the semaphore operations would bracket each SCSI command. Similar changes
could be made to the lp driver.
Note that interrupts can only be enabled while some driver owns the port,
and by implication a driver shouldn't up the semaphore if any interrupts
are pending.
I'm not happy with this solution, because it requires the MUTEX semaphores
to be pre-allocated for each of the ports that one might want to access
this way. And, it is conceivable that someone will come out with a
parallel port that does not sit at one of the standard addresses.
Now there's another wrinkle. I can think of some good reasons
why one might want to chain a PLIP connection off the back of a ZIP
drive. PLIP would want to "own" the ports whenever the other driver
didn't need them, so some sort of preemption is needed, as well.
A more dynamic high-level resource synchronisation mechanism
might be preferrable. How about a pair of higher-level operations
something like:
claim_resource( char *resource, void (*preempt)(void), int priority )
free_resource( char *resource)
where the resource is an arbitrary _symbolic_ resource name ? The semantics
should be obvious, but we would have to spell them out carefully.
The drivers that are prepared to share a port would agree on a
mechanism for constructing the names, like "pp378", and on a priority
policy.
Now there are some obvious performance weaknesses with this symbolic
approach, but I think it has the kind of generality that one wants in
a feature of the kernel proper. Of course, much more elaborate
resource schedulers could be designed. Are there other applications for
this sort of mechanism ? Does anyone know any standards for such
an interface ?
Can anybody think of a better way to do this ?
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------