From owner-freebsd-hackers Thu Apr 4 04:58:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA25820 for hackers-outgoing; Thu, 4 Apr 1996 04:58:22 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA25803 for ; Thu, 4 Apr 1996 04:57:46 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA03800 for hackers@freebsd.org; Thu, 4 Apr 1996 14:46:44 +0200 From: Luigi Rizzo Message-Id: <199604041246.OAA03800@labinfo.iet.unipi.it> Subject: soft disable of peripherals ? To: hackers@freebsd.org Date: Thu, 4 Apr 1996 14:46:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At times, there is the need to use I/O ports in strange ways, e.g. such in the case of the user-space quickcam driver: a user process directly drives the bits of the port. In order to this safely, the port should not be handled by the standard driver of the OS. For the parallel port, it often suffices to do "lptcontrol -p". For the serial port, there is no such a thing, so one has to reboot with "-c" and disable the port. I think it would be useful to have a general mechanism which could temporarily disable/reenable a given I/O port. As a minimum, it should check that noone is using the port at the moment, make the interrupt service routine just return, possibly set the port in some known state, and prohibiting access (other than "enable") to the port while disabled. Reenabling the port could just run some "init" routine for the specific port. If one wants to go further down this road, there might even be a set of ioctl to gain direct access to the registers of the port without having to open /dev/io. Is there any interest to implement such a feature ? I believe the ioctl which implements the enable/disable should be the same for all drivers. This does not mean that all drivers must implement it. As an example, just having it on the parallel and serial port would be ok (both ports are often used by HW hackers to drive the strangest devices attached to them). Cheers Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================