ingoldsby@calgary.UUCP (Terry Ingoldsby) (04/30/86)
Many thanks to all those who kindly informed me that system calls were legal within device drivers. Now I'll ask the question I meant to ask: Are OS9 system calls allowed within the interrupt service routine of device drivers, ie. the routine which executes when a device causes an interrupt. The reason that I ask this question is because it would be convenient to debug device drivers by putting output statements in the interrupt driven routines. Attempts to do this have not been successful. One additional question to all you OS9 system gurus out there. Are device drivers and there associated interrupt service routines subject to time slicing, as are normal processes? Thanks Terry Disclaimer: Nobody even cares what I think.
dibble@rochester.UUCP (05/05/86)
In article <103@vaxb.calgary.UUCP>, ingoldsby@calgary.UUCP (Terry Ingoldsby) writes: > were legal within device drivers. Now I'll ask the question I meant to > ask: Are OS9 system calls allowed within the interrupt service routine > of device drivers, ie. the routine which executes when a device causes > an interrupt. The reason that I ask this question is because it would > be convenient to debug device drivers by putting output statements in the > interrupt driven routines. Attempts to do this have not been successful. > > One additional question to all you OS9 system gurus out there. > Are device drivers and there associated interrupt service routines subject > to time slicing, as are normal processes? System calls are legal in interrupt routines. Since you only intend to use system calls for debugging you don't need to worry about efficiency. As an example of how OK it is to use system calls in the interrupt service routine: The interrupt service routine posts the sleeping read or write with an F$Send SVC. If you do I/O you will find that system state processes use system path numbers. You might want to check your system path table for good numbers. My memory is that interrupts are dissabled during interrupt service routines. While interrupts are disabled clock ticks are not processed so there is no time slicing. I have used error codes to return information from device drivers. It takes patience, but it works. Peter Dibble
draco@chinet.UUCP (Kent D. Meyers) (05/10/86)
ingoldsby@calgary.UUCP (Terry Ingoldsby) writes: >... Are OS9 system calls allowed within the interrupt service routine >of device drivers, ie. the routine which executes when a device causes >an interrupt. The reason that I ask this question is because it would >be convenient to debug device drivers by putting output statements in the >interrupt driven routines. Attempts to do this have not been successful. And dibble@rochester.ARPA (Peter C. Dibble) replies: >System calls are legal in interrupt routines. But, >If you do I/O you will find that system state processes use system >path numbers. The path numbers that user processes see and employ are not the true path numbers, but simply pointers to a sixteen byte (0-15) path table which is local to each process. The following code will return the true (System) path number for a running process' standard error path in ACCA: LDX >D.PROC Get Process Descriptor Address LEAX P$PATH,X Point to Path Table LDA 2,X Get True Path Number Standard Input (Path #0) would be at an offset of 0,X and Standard Output (Path #1) would be at an offset of 1,X. This translation is handled internally by IOMan for all user processes and is completely transparent to the user. But device drivers and interrupt handling routines run in the System State and access IOMan through a different set of vectors. These entry points use the path number passed in ACCA directly without doing the translation, assuming that it is a valid System Path number. And that is what causes the problems! You must somehow pass the true System Path to the routine. Another approach for passing debug information from a device driver is to utilize a part of memory which is invisible to OS9. The OS9 bootfile begins loading on an even page boundary, but the chance that it will end precisely at the last byte of a page is very slim indeed. This leaves an unused in the range of 1 to 255 bytes. The start of this area is defined by D.BTHI at locations $0068-69 on the Base Page. So you have two ways to go. If you wish to use I/O calls in the driver or interrupt handler itself, you can pass the System Path number via this protected memory. Or you can have the driver save its information in this area for later retrieval by the test program. Kent D. Meyers PO Box 266 Le Roy, MN 55951 (507)-324-5836 (After 8:30PM CDT) Net> ihnp4!chinet!draco