From owner-freebsd-hackers  Wed Nov 29 05:45:21 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id FAA15750
          for hackers-outgoing; Wed, 29 Nov 1995 05:45:21 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA15736
          for <hackers@freebsd.org>; Wed, 29 Nov 1995 05:44:51 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA24528; Thu, 30 Nov 1995 00:40:14 +1100
Date: Thu, 30 Nov 1995 00:40:14 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511291340.AAA24528@godzilla.zeta.org.au>
To: julian@ref.tfs.com, msmith@atrad.adelaide.edu.au
Subject: Re: more device driver question 8)
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> > spltty()
>> > 	tsleep(...)
>> > splx()
>> > 
>> > Does this imply that tsleep() restores the base interrupt level while
>> > it's running?
>> exactly,
>> It schedules another process, which will be at some OTHER
>> interrupt priority level, it does it 'atomicly' too..

>Ah.  This implies that interrupt priorities are kept on a per-process basis,
>correct?

They are kept in local variables.  Except above :-).

>So for a 'tty' device driver, I could safely say

>spltty()
>enable_interrupt()
>tsleep()
>splx()

>and be sure that interrupts from the device won't be enabled until after 
>the current process sleeps?  

The spltty() would do that.  I don't know what enable_interrupt() is.
Perhaps you meant disable_intr().  That would probably disable interrupts
forever.  Don't use disable_intr() except in short (< 10 usec) critical
regions.

Bruce