Messages in this thread | | | From | "Grant R. Guenther" <> | Subject | Simple resource synchronisation | Date | Thu, 11 Apr 1996 19:53:40 -0400 (EDT) |
| |
I guess I should say a bit more about what I mean about synchronising access to chained parallel port devices.
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 --------------------------------------------------------------------------
| |