From owner-freebsd-hackers  Mon Dec  2 18:35:04 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA00951
          for hackers-outgoing; Mon, 2 Dec 1996 18:35:04 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA00937
          for <hackers@freebsd.org>; Mon, 2 Dec 1996 18:34:59 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id NAA11739; Tue, 3 Dec 1996 13:18:09 +1100
Date: Tue, 3 Dec 1996 13:18:09 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199612030218.NAA11739@godzilla.zeta.org.au>
To: msmith@atrad.adelaide.edu.au, tony@nlanr.net
Subject: Re: Driver help
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> - It's probably not actually necessary to disable tty interrupts
>   while doing any of the read in this particular driver, but for
>   many the possibility of conflict is real.

Interrupts should not be disabled while doing the uiomove() for
several reasons:
- it's antisocial to disable interrupts for a long time.
- uiomove() is certain to take a long time if it blocks because it
  gets a pagefault and has to read the page from a disk.
- disabling interrupts doesn't actually disable them if uiomove()
  blocks.  Then the process doing the reading will usually sleep
  and another process may run.  You have to assume that uiomove()
  blocked and another process ran inside the driver and clobbered all
  the clobberable variables.  You have to do this even if the driver
  doesn't use interrupts so that disabling interrupts is unnecessary.
  There is no such thing as exclusive access, since dup() or fork()
  may have duplicated an open file descriptor for the device.

Bruce