avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) (02/16/88)
In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: > Does anyone know if UNIX supports a "Connect to Interrupt" facillity > similar to VMS or RSX. Failing an "Out of the Box" solution, has > anyone cobbled something together? Target system is a 68000 VME based > system. Any takers? UNIX provides a facility called "signals". Signals may be sent by processes, open device files, or by the kernel. Most interrupts are used within device drivers, but it is trivially simple to write a device driver which will send the appropriate signal, to processes that have opened it, when device receives an interrupt. Once the driver is installed, you open its device file to connect to the interrupt, and you close it to disconnect. You may use any signal - its your system - but it is good programming practice to restrict yourself to standard signal semantics: 01 Hardware termination (hangup) 02 Catchable interrupt 03 Quit and dump core 09 Kill absolutely and immediately (no cleanup!) 16 User defined signal 1 17 User defined signal 2 Adam Reed (mtgzz!avr)
gwp@hcx3.UUCP (02/19/88)
} /* Written 2:08 pm Feb 15, 1988 by avr@mtgzz.UUCP (Adam Reed) } In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: }> Does anyone know if UNIX supports a "Connect to Interrupt" facillity }> similar to VMS or RSX. Failing an "Out of the Box" solution, has }> anyone cobbled something together? Target system is a 68000 VME based }> system. Any takers? } UNIX provides a facility called "signals". [ ..] } , but it is trivially simple to write a device } driver which will send the appropriate signal, to processes that have } opened it, when device receives an interrupt. This is correct, but may not be what is needed, depending upon the performance constraints involved. UNIX signals are notoriously slow, and if the concerned process needs to run in anything less than 200 microseconds or so (your mileage may vary) after the device triggers the interrupt, you can forget it. Of course "Chuck" didn't say whether there where any time constraints involved. _____________________________ | Gil Pilz | | Harris Computer Systems Div.| | 2101 W. Cypress Creek Rd. | | Ft. Lauderdale, FL 33309 | | UUCP:gwp@ssd.harris.com | -----------------------------
gwhisen@ccvaxa.UUCP (02/20/88)
Gould's UTX/2.1 allows processes to specify a signal to sent to the process when a given external (or internal) interrupt is generated. It also has the capability to "directly connect" to interrupts so that the interrupt routine is executed in the process. This gives the user the ability to write device control software without changing the kernel. Gary Whisenhunt. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!gwhisen 1101 E. University, Urbana, IL 61801 ARPAnet: gwhisen@gswd-vms.arpa
news@udenva.cair.du.edu (netnews) (02/20/88)
In article <48200002@hcx3> gwp@hcx3.UUCP writes: > >} In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: >}> Does anyone know if UNIX supports a "Connect to Interrupt" facillity >}> similar to VMS or RSX. > >} UNIX provides a facility called "signals". [ ..] >} , but it is trivially simple to write a device >} driver which will send the appropriate signal, to processes that have >} opened it, when device receives an interrupt. > >This is correct, but may not be what is needed, .... 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. This is all based on the RSX version, I can't speak for VMS. Interestingly, some benchmarks I tried showed that CINT was only marginally faster then doing the same thing with a driver. Of course, given the difference in systems, under Unix it may speed up significantly. Rich the PDP holdout Rockwell International Computer Aided Manufacturing and Control Golden, CO Double your VAX's speed and give the performance of the 11/23!!!!!
gwp@hcx3.SSD.HARRIS.COM (02/23/88)
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 | -----------------------------
mouse@mcgill-vision.UUCP (der Mouse) (03/13/88)
> In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: >> Does anyone know if UNIX supports a "Connect to Interrupt" facillity >> similar to VMS or RSX. Not out-of-the-box. A kernel hacker can build something of the sort. Presumably you need low interrupt latency. Good luck: UNIX has a tendency to spend large amounts of time (hundreds of microseconds) with interrupts blocked, because part of the design philosophy is that any amount of time a human can't notice is irrelevant. This is not the case if you are doing "real-time" work. >> has anyone cobbled something together? Target system is a 68000 VME >> based system. Any takers? At McGill here we built a fairly extensive system for robot control that required "real-time" response. We got it through the use of some horrible kludges and by throwing security completely out the window. I can provide details if anyone is really interested; the system is a MicroVAX-II running what started out as 4.3BSD. (I say "started out as" because we have had to do a good deal of hacking on it.) In article <3617@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > UNIX provides a facility called "signals". Signals may be sent by > processes, open device files, or by the kernel. [suggests building a > driver to send the process a signal on a device interrupt] This will work fine, if you can tolerate the resulting latency. A signal can easily be delayed by twenty microseconds even if the process is in-core, which is probably more latency than can be tolerated if this application is such that it would use the connect-to-interrupt driver on VMS. And if the process happens to be swapped out to disk at the moment, forget it. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
beres@cadnetix.COM (Tim Beres) (03/25/88)
In article <991@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > >At McGill here we built a fairly extensive system for robot control >that required "real-time" response. We got it through the use of some >horrible kludges and by throwing security completely out the window. I >can provide details if anyone is really interested; the system is a >MicroVAX-II running what started out as 4.3BSD. (I say "started out >as" because we have had to do a good deal of hacking on it.) > I've spent much time using RMX and VersaDos, both real-time OS's. What I want to know is why ya'll hacked up Unix. Why not just get RMX on an SBC, connect via ethernet to a UNIX system, and run with that? Cost is one concern no doubt. Plus the academic thrill of hacking UNIX. I've always thought marrying two systems, each of which is excellent (no flames, please) at what it does, would work nicely. Is anyone *out there* doing this type of thing? -- Tim Beres Cadnetix 303/444-8075 x221 5775 Flatirons Pkwy {uunet,boulder,nbires}!cadnetix!beres Boulder, CO 80301 beres@cadnetix.com <disclaimers: my thoughts != Cadnetix's>
aglew@ccvaxa.UUCP (03/25/88)
> In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: >> Does anyone know if UNIX supports a "Connect to Interrupt" facillity >> similar to VMS or RSX. The upcoming release of Gould UTX supports connected interrupts. One of the reasons I came to work for Gould's RT UNIX group was seeing the hoops Mouse and Crazy Horse were jumping through at McGill. For more information contact your local Gould sales office... Hi, Mouse! I'll be home over Easter - see you Monday at Basha's? Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have MX records aglew@xenurus.gould.com - if you don't ...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.