From owner-freebsd-hackers Fri Sep 19 22:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05275 for hackers-outgoing; Fri, 19 Sep 1997 22:17:26 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA05270 for ; Fri, 19 Sep 1997 22:17:24 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17900; Fri, 19 Sep 1997 22:17:20 -0700 (MST) From: Terry Lambert Message-Id: <199709200517.WAA17900@usr02.primenet.com> Subject: Re: UserLand Device Driver Thingys To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Sat, 20 Sep 1997 05:17:19 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Sep 19, 97 07:49:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why is it so impossible to have an arbitruary interrupt passed to a > userland process, very much like a signal? It would be nice to be able to > write device drivers that could open sockets and make data available on > the network in an arbitruary way. Since interrupts can be cli() in a > userland process I don't see much harm in making them available. Sorry, CLI and STI are protected instructions in userland. To accomodate what you want, interrupt delivery would have to be virtualized, so that the interrupt is noted an blocked at interrupt level, and then the interrupt is handled and unblocked *not* at interrupt level. This would let you call the "unblock" from a user mode process via a system call (or ioctl, or whatever -- I expect it would be set to handle interrupts, and unblocked, via ioctl to /dev/io). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.