Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Mar 95 16:57:10 MST
From:      terry@cs.weber.edu (Terry Lambert)
To:        davidg@Root.COM
Cc:        vernick@cs.sunysb.edu, freebsd-hackers@FreeBSD.org
Subject:   Re: help with splbio, splnet, spl...
Message-ID:  <9503302357.AA29610@cs.weber.edu>
In-Reply-To: <199503302344.PAA00262@corbin.Root.COM> from "David Greenman" at Mar 30, 95 03:44:02 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> >Can someone point me to some documentation that explains how the spl
> >interrupts work?  For example, in the Scsi code (scsi_scsi_cmd in
> >scsi_base.c) just before a command is sent to the adapter, a call is
> >made to splbio().  Does this mask all I/O interrupts? Network interrupts
> >too?  
> 
>    It prevents interrupts from devices that are "bio" type. This is basically
> all disk controllers. Tty devices (such as serial ports) are blocked with
> spltty(). Network interrupts are blocked with splimp(). splhigh() and
> splclock() block all interrupts except "fast" interrupts. "fast" interrupts
> are special and can be explained if necessary; they are currently only used in
> the sio driver.


Or more simply:

increasing
priority
    ^
    | fast --------------------------------------------------->
    |
    | splclock -------------------------------------> |
    |                                       ,---------'
    | splimp -----------------------------> |
    |                             ,---------'
    | spltty -------------------> |
    |                   ,---------'
    | splbio ---------> |              B L O C K E D
    |                   |
    +---------------------------------------------------------

It's a tiered interrupt scheme.  You can block all interrupts
at or below a specified priority while you are doing high
priority stuff so that it gets done in time.  The "fast"
interrupts can't be blocked.

This way time critical stuff gets handled when it needs to
be instead of being put off.  For serial ports, since they
have a limited queue depth, it's important to unload the
queues "fast" because if you don't you can easily get a data
overrun.

I don't have the header files currently available or I'd have
drawn a better (more comprehensive) picture.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503302357.AA29610>