Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!homxb!hropus!ki4pv!codas!novavax!hcx1!hcx3!gwp
From: gwp@hcx3.SSD.HARRIS.COM
Newsgroups: comp.unix.questions
Subject: Re: Unix Interrupts
Message-ID: <48200003@hcx3>
Date: 22 Feb 88 16:29:00 GMT
References: <3617@mtgzz.UUCP>
Lines: 51
Nf-ID: #R:mtgzz.UUCP:3617:hcx3:48200003:000:2766
Nf-From: hcx3.SSD.HARRIS.COM!gwp    Feb 22 11:29:00 1988


Rich (the PDP holdout) points out:
} I don't think it is what the original question was asking. Connect to 
} interrupt or CINT, allows a single task to directly connect to an 
} interrupt service routine (ISR). Note that only this task is connected,
} so the controlled device is strictly private. Using a driver would allow
} other tasks to use the device. Further, CINT will not let the user 
} connect to devices already in use and when the using task exits, it frees
} the device for others to CINT to. Also, the ISR has nearly full access to 
} all the variables of the non-ISR code directly. CINT does not support any
} type of I/O request queue. 

I didn't _think_ that's what the original question was asking, still
signals (combined with some funky ioctl calls to provide exclusive
access) _could_ provide a roughly equivalent, if horribly slow,
capability.

W/regards to implementing something closer to CINT (i.e. modifying the
systems interrupt vector to point to a section of user code) you run
into a couple of problems.  The first is preventing the user's text
and data pages from being paged or swapped. No problem, use plock(2).
The second is a little more difficult and depends of the virtual
memory mechanism used by your machine. Our machine uses separate
system and user page tables.  The interrupt service vectors contain
virtual addresses that are translated using the system page tables.
Therefore any user code or data that needs to be accessed at interrupt
level would have to be mapped into the system's virtual address space.

W/regards to the properties of exclusive access I would think the
device configuration code would have to be altered to recognize that
you have configured a device as being "CINT-able" and the CINT service
would have to be able to recognize the difference between a device
configured this way and a normal system-driven device. After having
done a CINT, the interrupt service vector would look just like any
other "system" device and further CINT's would be rejected (until,
of course, you performed a "DINT")

I think this method of dealing with devices could have a lot of
advantages, particularly if you combine it with the capability to map
device registers and memory (on memory mapped I/O systems that is)
into user virtual address space.  This way you could have a
high-priority user processes map the device controller registers,
connect intself to the device interrupt, then scream away without the
overhead of system entry and exit for every I/O or control operation.
	 _____________________________ 
	| Gil Pilz                    |
	| Harris Computer Systems Div.|
	| 2101 W. Cypress Creek Rd.   |
	| Ft. Lauderdale, FL  33309   |
	| UUCP:gwp@ssd.harris.com     |
	 -----------------------------